CSV Export

The chart shows you structure visually. The data export pipeline gives you the raw data behind it — every swing, every cycle count, every hierarchy position — for analysis in spreadsheets, databases, Python, R, or any tool you prefer.

STP offers two complementary export methods: CSV export for historical backfill (63 columns of hierarchical swing data via TradingView's native export), and webhook alerts for live forward feed (structured JSON payloads delivered to your endpoint on every confirmed swing). Both deliver the same atomic data and write to the same database schema.

Unlike SSI PRO's single-timeframe export, STP's export captures the state of all 10 timeframes simultaneously, giving you a complete multi-timeframe dataset whether you're downloading history or receiving live events.

How to Export

1. Open your chart with STP applied
2. In the indicator settings, navigate to Group ⑨ (Data Export)
3. Enable "CSV Export"
4. Right-click anywhere on the chart
5. Select "Export chart data"
6. Choose your date range and save the CSV file

The export includes every bar in the selected range. On bars where no swing occurred, the event columns (Swing_Event, Swing_Type) contain NaN/empty values while the state columns retain their last-known values.

Right-click the chart and select "Export chart data" to download the CSV file containing all 63 STP columns.

The 63 Columns

The export is organized into two categories: per-timeframe columns (6 columns × 10 timeframes = 60) and global columns (3).

Per-Timeframe Columns

Each of the 10 timeframes exports 6 columns using the naming pattern {TF}_{Field}:

Timeframe Prefixes

The 10 timeframe prefixes, from highest to lowest:

Global Columns

Three columns capture cross-timeframe information:

Understanding the Data

State Columns vs. Event Columns

This distinction is critical for working with the data correctly.

State columns (_Cycle, _Phase, _Price, _Time, _Dir, _TDays) persist their values across bars. Once a Weekly swing high confirms and sets W_Phase to 1, that value remains 1 on every subsequent bar until the next Weekly swing changes it. These columns represent the current state of each timeframe — what's true right now.

Event columns (Swing_Event, Swing_Type) are populated only on bars where a swing was confirmed. On all other bars, they contain NaN. These columns mark the moments when something happened.

Practical consequence: If you filter the CSV to rows where Swing_Event is not NaN, you get a table of all swing events with their full hierarchical context. If you read the data row-by-row, the state columns give you a snapshot of all 10 timeframes at every bar.

Reading the Odometer (Full_Hierarchy)

The Full_Hierarchy column encodes all 10 cycle counts into a single integer using positional notation:

Example: Full_Hierarchy = 1203007014

To decode in Python:

Note: The odometer uses single digits per position, so cycle counts above 9 at any level will overflow into the adjacent position. This is rare in practice — a timeframe would need 10+ swings before its parent resets the counter — but be aware of it when decoding very long datasets.

Dir Encoding

The _Dir column encodes both the post-swing direction and the swing pattern in a single integer:

Decoding:

• Direction = sign of the value (positive = up, negative = down)
• Pattern = absolute value (1 = regular, 2 = ob_reversal, 3 = ob_continuation)

Python:

Excel:

This encoding uses no additional CSV columns — pattern information piggybacks on the existing Dir column. Prior to v2.0.1, Dir only used values 1 and -1. Code that reads Dir as a simple direction indicator will still work (positive = up, negative = down) but will miss the pattern information.

Reading Phase + Dir Together

_Phase and _Dir are related but encode different information:

• _Phase tells you the type of the last confirmed swing: 1 = the last swing was a High (Top), 0 = the last swing was a Low (Bottom)
• _Dir tells you the current trend direction AND the pattern type: the sign indicates direction (positive = up, negative = down), and the magnitude indicates the pattern (1 = regular, 2 = ob_reversal, 3 = ob_continuation)

For simple direction checks, the sign relationship still holds: when Phase = 1 (last swing was High), Dir is negative (now trending down). When Phase = 0 (last swing was Low), Dir is positive (now trending up).

The magnitude adds pattern context that wasn't previously available in the CSV export. A Dir value of 3 means the swing was produced by an OB continuation pattern and the trend is now moving up — useful for filtering analysis by pattern type.

CSV Data Only Mode

For deep historical exports, STP offers a mode that bypasses TradingView's 500-label drawing limit.

The problem: TradingView limits visual labels to 500 per indicator instance. On a daily chart with 50 years of data and 4 active timeframes, you'd hit this limit quickly — meaning the indicator would only show labels for recent history.

The solution: Enable "CSV Data Only (No Labels)" in Group ⑨ (Data Export). This runs all swing detection, classification, hierarchy tracking, and CSV state computation on every bar — but skips label and line drawing entirely. Without visual objects consuming the 500-label budget, the indicator processes the full chart history.

What you get: A complete CSV with all 63 columns covering the entire visible date range, including decades of data on instruments with long histories (like major stock indices or commodities).

What you lose: No labels or lines appear on the chart. The chart looks as if the indicator isn't applied (except for the settings panel being visible). This mode is purely for data extraction.

When to use it: Building historical databases, backtesting across decades, academic research on cycle behavior, or any workflow where you need complete data and don't need visual chart output.

Working with the Data

Recommended Extraction Method

The reliable way to extract swing events is per-TF phase change detection. For each timeframe, scan its {TF}_Phase column row by row. When the value changes (0→1 or 1→0), that row marks a confirmed swing:

• Phase changes from 0 to 1 → Swing High (Top)
• Phase changes from 1 to 0 → Swing Low (Bottom)

Python:

Why not use Swing_Event? The Swing_Event and Swing_Type global columns have a known limitation: when multiple timeframes fire on the same bar, only the last one is recorded — the others are overwritten. Per-TF Phase columns are independent and never overwrite each other.

This method guarantees strict alternation (HIGH-LOW-HIGH-LOW) by construction and captures all swing events including OB continuation pairs.

Extracting All Timeframes

Repeat the phase-change scan for each timeframe you need:

Converting Timestamps

The _Time columns use Unix timestamps in milliseconds (milliseconds since January 1, 1970). Convert to readable dates:

Python:

JavaScript:

Excel:

Format the cell as Date/Time.

Note on dates: The _Time column uses session close timestamps, which match the trading date shown on the TradingView chart axis. For futures instruments with overnight sessions (e.g., ES1!, CL1!), this ensures a Monday swing shows as Monday — not Sunday evening when the session opened.

Building a Swing Timeline

Use the per-TF phase-change extraction to build a chronological timeline across all timeframes:

This produces a clean chronological table of every swing across all timeframes, with correct dates and pattern types.

Detecting Cycle Resets

When a parent timeframe confirms a swing, all child counters reset. You can detect these resets by watching for drops in cycle counts:

Each reset row corresponds to a bar where a Monthly (or higher) swing confirmed and reset the Weekly counter to 1.

Measuring Cycle Maturity

The cycle count tells you where you are within a parent cycle. If historical Monthly cycles typically contain 8–12 Weekly swings, and the current W_Cycle is 11, the cycle is mature — a Monthly-level reversal may be approaching.

STP + SSI PRO Dual Export

If you run both STP and SSI PRO on the same chart, both indicators contribute their columns to the CSV export. This gives you the best of both worlds:

• STP columns (63): Multi-timeframe hierarchy, cycle counts, cross-timeframe state
• SSI PRO columns: Single-timeframe detail — ExtremeTimestamp vs ConfirmTimestamp, pattern codes, bar index

The combined export lets you cross-reference single-timeframe swing detail (from SSI PRO) with multi-timeframe context (from STP) in the same dataset.

Workflow:

1. Apply both indicators to the same chart
2. Enable CSV Export in both indicators' settings
3. Right-click → Export chart data
4. The resulting CSV contains columns from both indicators plus TradingView's standard OHLCV

Running STP and SSI PRO together provides the most comprehensive swing data export — multi-timeframe hierarchy plus single-timeframe detail in one file.

Building a Swing Database

CSV export and webhook alerts are two halves of the same data pipeline. CSV gives you the historical backfill — every swing the indicator has ever detected across the full chart history. Webhook alerts give you the live forward feed — every new swing as it confirms in real time. Both deliver the same atomic data, so they write to the same database table.

Database Schema

The recommended schema stores one row per swing event with atomic fields only. No derived metrics are stored — range, duration, ratios, and velocity are all computed at query time from the atomic values. This avoids redundancy, prevents conflicts across timeframes with different natural units, and gives you full flexibility to derive whatever you need.

Why atomic fields only: The swing_time column is a Unix millisecond timestamp — universal and unit-agnostic. To compute duration, subtract the previous swing's timestamp. To compute range, subtract the previous swing's price. This works identically whether the swing is a 15-minute swing (where duration is minutes) or a yearly swing (where duration is months). No unit assumptions are baked into the schema.

Why per-timeframe cycle columns: The 10 c_* columns store a snapshot of every timeframe's cycle count at the moment the swing confirmed. This enables direct nesting queries — "show me all Daily swings that occurred during the 7th Weekly cycle" is a simple WHERE clause, not a string-parsing exercise.

CSV Import Workflow

1. Export historical data — Use CSV Data Only mode for full history
2. Parse the CSV per timeframe — For each TF, scan {TF}_Phase row by row. When the phase value changes, that row is a swing event
3. Extract swing data — Pull {TF}_Price, {TF}_Time, and decode pattern from {TF}_Dir (1=regular, 2=ob_reversal, 3=ob_continuation)
4. Sort chronologically — Sort all extracted swings by swing_time, with higher TFs first for same-timestamp events (ensures correct parent-before-child hierarchy computation)
5. Handle same-time collisions — If two swings at the same TF share the same timestamp (OB zigzag pairs on 2D), offset the second by 1ms
6. Insert rows — One row per swing event. If using a database trigger for hierarchy computation, insert oldest first
7. Verify — Run alternation check (zero violations expected) and pattern distribution check

A production-grade Python importer (import_csv.py) is available in the STP Pipeline Manual that handles all these steps automatically, including validation and error reporting.

Webhook Alerts — Live Data Feed

Webhook alerts complement CSV export by delivering swing data in real time. Every confirmed swing fires a structured JSON payload to a URL you specify — the same atomic data that the CSV contains, arriving automatically as new swings are detected.

How It Works

1. Enable "Webhook Alerts" in the indicator settings (Group ⑨ Data Export)
2. Create a TradingView alert on the indicator (right-click → Add Alert → select STP)
3. In the alert dialog, check "Webhook URL" and enter your endpoint
4. Save the alert — it now runs on TradingView's servers

Every confirmed swing across all enabled timeframes fires a single JSON payload to your webhook URL. A Weekly swing high, a Daily swing low, a 15-minute reversal — each one becomes one HTTP POST to your endpoint.

Create a TradingView alert on STP and enter your webhook URL — every confirmed swing is delivered automatically.

One Chart, One Alert, All Timeframes

Because STP detects all 10 timeframes simultaneously on a single chart, you only need one alert per instrument. Place the indicator on a 15-minute chart (to capture all timeframes), enable the timeframes you want, enable the webhook toggle, and create the alert. That single alert covers everything from 15-minute swings to yearly swings on that instrument.

Chart timeframe determines which timeframes are captured:

For the broadest coverage, use a 15-minute chart.

Multiple instruments: Each instrument needs its own alert. Tracking 5 instruments requires 5 alerts — one per symbol, each on its own chart instance with STP configured and the webhook toggle enabled.

Alert Behavior

Webhook alerts only fire on confirmed bars — the final update of a closed bar. This prevents historical replay alerts from flooding your endpoint when the alert is first created. When TradingView creates an alert, it runs a brief warm-up replay of recent history; the confirmation gate ensures no phantom alerts are generated during this replay.

Once a TradingView alert is created, it runs independently on TradingView's servers. You can change the chart timeframe, switch to a different symbol, or even remove the indicator from the chart — the alert continues running with the exact settings it had when you created it.

Important: The alert is a frozen snapshot. If you later change indicator settings (enable a new timeframe, switch OB mode, etc.), the existing alert does not pick up those changes. You need to delete the old alert and create a new one.

TradingView alert limits: The number of active alerts depends on your TradingView subscription plan. Since each instrument requires a separate alert, users tracking many instruments may need a higher-tier TradingView plan.

Webhook Payload

Each swing event delivers a JSON payload with 12 atomic fields plus 10 per-timeframe cycle counts:

Payload Field Reference

The cycles object contains keys for all 10 timeframes (15m, 1H, 4H, D, 2D, 3D, W, M, Q, Y), each with the current cycle count. This is the key to nesting queries — when a Daily swing fires, cycles.W tells you which Weekly cycle it occurred in.

Receiving Webhooks

TradingView sends an HTTP POST with the JSON payload to your webhook URL. You need a receiver that parses the JSON and inserts it into your database. This can be minimal — a Python Flask app with SQLite is roughly 30 lines:

For production use, consider cloud-hosted receivers: Supabase Edge Functions, AWS Lambda with API Gateway, Google Cloud Functions, or no-code platforms like Make.com or Zapier that can route webhooks directly to Google Sheets, Airtable, or Notion databases.

CSV + Webhook Together

The typical workflow combines both:

1. Backfill: Export historical data via CSV, import into your database
2. Go live: Enable webhook alerts, point them at your receiver
3. Done: Historical data and live data flow into the same table automatically

The UNIQUE(instrument, swing_time, timeframe) constraint prevents duplicates if a CSV re-export overlaps with webhook data.

Querying Your Database

Once swing data is in the swing_events table — whether from CSV import, webhook, or both — all analysis happens through standard SQL queries. Every metric you'd compute in Python or Excel can be expressed as a query against the atomic fields.

Basic Queries

Nesting Queries (Using Per-TF Cycle Columns)

The c_* columns make nesting queries direct — no string parsing or integer decoding needed.

Derived Metrics (Duration, Range, Ratios)

Duration and range are computed from sequential rows using window functions. No pre-stored derived fields needed.

The user chooses the duration unit that fits the timeframe — /86400000 for days on Weekly swings, /3600000 for hours on 4-Hour swings, /60000 for minutes on 15-minute swings. One timestamp field, any unit.

Confluence Detection

Find where multiple timeframes detected swings at the same point (within a time window):

Cycle Maturity Analysis

Complete Column Reference

All 63 columns in export order, from highest timeframe to lowest:

Next Steps

• Tooltips & Metrics — The same data shown visually in chart tooltips
• Settings — Data Export settings (Group ⑨) including CSV and Webhook configuration
• Overview — How the data pipeline fits into the broader STP system
• Glossary — Definitions for all terms used in this page