PostHog Product Analytics Pipeline with BigQuery
1) Know the one limit that matters
PostHog's /events REST API - the endpoint ingestr reads - does not return a complete history for a multi-day window, and gives no indication that anything is missing. Measured against one project, --full-refresh each time, three repeats per window, with deterministic results:
| Window | Days | Events in PostHog | Events loaded | Days actually covered |
|---|---|---|---|---|
| 3 days | 3 | 1,679 | 545 | 1 |
| 7 days | 7 | 3,090 | 2,619 | 7, but 15% short |
| 31 days | 31 | 16,925 | 673 | 1 |
| 95 days | 95 | 42,354 | 1,551 | 4 |
| 205 days, sparse | 205 | 141 | 141 | all - complete |
| one day | 1 | exact | exact | 93 days tested, all exact |
The loss is not a function of how wide the window is. A three-day window returned a single day while a seven-day window spanned all seven, and a 205-day window over sparse data returned everything - so the limit tracks the volume of events in the window, not its width. There is no usable rule to exploit, because the seven-day case looks complete and is 15% short.
Warning
A single day is the only window that is reliably exact. Backfill events a day at a time, always. This is not a performance tip - a wider window on a busy project silently drops most of your history with no error and no warning in the run output.