Search Interest, Daily
Daily Google search interest per US equity ticker as one continuous series, already rescaled so values are comparable across the full history rather than only within a single query window.
google_trends_daily - the dataset name to pass to the Obscura API.
What one row means
One ticker's search interest on one day, rescaled onto a single scale that is comparable across the whole history.
One row per (ticker, trend_date).
Derived in-database from google_trends.
Point-in-time availability
Every Obscura dataset carries available_date: the calendar day the publisher made the row
available, day-of, with no session rounding. It is the one column a backtest filters on, and it means the
same thing on every dataset in the catalog.
For google_trends_daily: derived: available_date = the available_date of the raw frame this day came from - the day this pipeline captured the window containing it. Rescaling changes a value, never when it became knowable, so the stitched row inherits its source frame's availability unchanged and never claims to have existed before the scrape that produced it.
Refresh cadence
Obscura refreshes google_trends_daily daily - the most frequent scheduled job that re-collects or re-exports it. This is Obscura's own pipeline cadence, not the upstream publisher's release schedule; when a row became public is recorded per row in available_date.
Schema - 10 columns
The full public column list for google_trends_daily, with the meaning of every field. The same
schema is served unauthenticated at https://api.obscura.trade/v1/catalog/google_trends_daily.
| Column | Type | Description |
|---|---|---|
| ticker | text · not null | Equity ticker the interest was measured for. |
| trend_date | date · not null | The day this score describes. |
| available_date | date | PUBLIC-availability date: inherited from the raw frame this day was taken from - the day this pipeline captured the window containing it. Rescaling moves a value onto a common scale; it does not make the value knowable any earlier, so this is never earlier than the source frame's own capture day. |
| score | double precision · not null | **The stitched score - the column to use.** The raw window-relative score multiplied by its window's rescale factor, so values from different query windows sit on one scale and a multi-year daily series can be read straight off. Comparable across time for a single ticker; see the module note on cross-ticker comparison. |
| raw_score | double precision · not null | The score exactly as Google returned it for its own window (0-100 within that window). Kept so the rescale is auditable and reversible - dividing `score` by this gives back `scale_factor` - and so a consumer that wants the untouched value never has to join back to the raw table. |
| scale_factor | double precision · not null | The multiplier applied to `raw_score`. Derived from the ratio of this ticker's monthly anchor series to the daily tile's own monthly means over the months the tile fully covers. |
| scale_basis | text · not null | HOW `scale_factor` was derived - `monthly_anchor` or `overlap_chain`. Read this BEFORE `anchor_months` or `overlap_days`: the two methods carry their evidence in different units and only one of those columns is meaningful per row. `monthly_anchor` matched the window's whole-month means to the ~21-year monthly series; `overlap_chain` scaled the window onto an already-scaled neighbour through the days they share, which is what makes the rolling 30-day tier joinable at all (it can never contain three whole months, so it can never be monthly-anchored). |
| anchor_months | integer · not null | Whole months that backed `scale_factor` when `scale_basis` is `monthly_anchor`; 0 otherwise. A tile anchored on 8 months is well pinned, one anchored on 1 is a guess - the column exists so a consumer can filter on that rather than trusting every point equally. |
| overlap_days | integer · not null | Days shared with the already-scaled neighbour when `scale_basis` is `overlap_chain`; 0 otherwise. The overlap method's evidence count, kept in its own column because days and months are not interchangeable and a single mixed-unit field would quietly poison whatever filtered on it. |
| source_window_key | text · not null | Which raw normalization window this day came from (`recent_daily`, `deep_daily:<start>`). Carried through so a stitched point can always be traced back to the exact frame and factor that produced it. |
Access google_trends_daily
Two delivery paths, one identifier. Both require an Obscura account and an active subscription; the catalog entry and the schema above are public.
import obscura
client = obscura.Client("obs_live_…")
df = client.query(
dataset="google_trends_daily",
symbols=["NVDA", "AAPL"],
start="2024-01-01",
)Create a free account Browse all 122 datasets
Frequently asked questions
What is in the google_trends_daily dataset?
Daily Google search interest per US equity ticker as one continuous series, already rescaled so values are comparable across the full history rather than only within a single query window. One ticker's search interest on one day, rescaled onto a single scale that is comparable across the whole history.
How do I avoid look-ahead bias with google_trends_daily?
Filter on google_trends_daily.available_date, the day the publisher made the row public. For this dataset that date is derived as follows - derived: available_date = the available_date of the raw frame this day came from - the day this pipeline captured the window containing it. Rescaling changes a value, never when it became knowable, so the stitched row inherits its source frame's availability unchanged and never claims to have existed before the scrape that produced it. A query of the form WHERE available_date <= '<as-of date>' never sees a row before it existed.
In what formats can I get google_trends_daily?
As a Parquet bulk export (POST https://api.obscura.trade/v1/download) or as JSON from the typed query API (POST https://api.obscura.trade/v1/query), both with dataset="google_trends_daily". The column schema is public at https://api.obscura.trade/v1/catalog/google_trends_daily.
Can I filter google_trends_daily by company or symbol?
Yes. google_trends_daily carries ticker, the column the API's symbols filter resolves against.
How often is google_trends_daily updated?
Obscura refreshes google_trends_daily on a daily schedule - that is the most frequent scheduled job that re-collects or re-exports the table. It is Obscura's own pipeline cadence, not the upstream publisher's release schedule; when the publisher makes a row available is described by the availability rule above, and is recorded per row in available_date.