Why am I missing attribution / first-touch data?

What broke

GL#368 — first-touch attribution wasn’t being saved. The part of our system that records a visitor’s very first touch (the source, campaign, and landing page they arrived on) hit a permission gap that only appeared under live conditions, so each first-touch record was rejected instead of saved. In our development environment it happened to work, which is why it slipped through. The pixel still captured first-touch details in the visitor’s browser, but the saved record that the first-touch reporting is built on (per GL#361) silently failed for each one. Net effect: the Acquisition card on /dashboard/analytics and the source-breakdown on /marketing-acquisition showed UTMs only for visitors who had hit a page very recently — returning visitors whose first touch predated the deploy were shown as Direct.

GL#369 — the events-used number was shown but never updated. The billing page’s Pixel Events This Period tile and the internal admin usage view both displayed an events-used count that nothing in the system was actually keeping current — it was read in many places and updated in none. It had become a display-only number after an earlier refactor, with nothing left to refresh it. Result: every workspace showed 0 events used regardless of real traffic, even ones processing millions of events per day. Quota enforcement runs on a completely separate path that always read real usage directly, so it was correct the whole time — this bug only affected what was displayed, not throttling. It was customer-impacting because a merchant looking at /billing would conclude they’d used 0 of their plan quota regardless of reality, which makes mid-month plan-upgrade decisions opaque.

GL#370 — a noisy Stripe error at startup. Every startup was logging a harmless Stripe-related error because a database setup step had been applied in the wrong order — one piece of structure was being referenced before the step that created it had run. Customer-facing impact was zero (our Stripe sync catches it and recovers automatically), but the noise made it harder to spot real Stripe-related errors in the logs. Bundled into the same ship for documentation completeness.

Symptoms you may have noticed

• Acquisition card on /dashboard/analytics showing fewer source/campaign attributions than expected, with returning visitors classified as Direct when they had previously been classified as Paid Search / Paid Social / Email.
• Source-breakdown on /marketing-acquisition missing rows for utm_source values you know are running in active campaigns.
• Pixel Events This Period tile on /billing stuck at 0 regardless of how many real events your store is generating.
• The workspace usage view in the admin area showing 0 events used for every workspace.
• A harmless Stripe-related message appearing at startup — only visible to our team in the internal logs, never to merchants.

If your dashboard otherwise looked fine — pageviews and revenue counts were correct, you just had fewer attributed UTM sources than you expected — you were hitting GL#368. Pageviews, sessions, payments, and goal events all wrote to separate analytics datasets that were never affected.

What we fixed

• First-touch saving made resilient. The path that records first-touch attribution now has the right permissions across all environments, so a single misconfigured credential can no longer silently drop records. An automated build check confirms every analytics write has sufficient access for its destination — the build fails if a future change reintroduces a silent permission error.
• Hourly recalculation of the events-used number. A new scheduled job recalculates the true events-used count from your real traffic every hour and refreshes the displayed number. It’s calculated from the source each time rather than nudged one event at a time, which makes it self-correcting — the number converges to the truth even if an update is ever missed. An automated build check also blocks any future display value that’s shown in several places but never kept current.
• Stripe startup ordering corrected. The Stripe database setup steps now run in the correct order using a safe, re-runnable fix, so the harmless startup error no longer appears. We also added an internal health check that flags it immediately if any required Stripe setup ever goes missing again — surfacing it in real time instead of leaving it buried in the logs.

Backfill window

The last 7 days of first-touch data were re-populated from your existing pageview history for every merchant. We replayed every pageview captured between 2026-04-29 and 2026-05-05 through the now-fixed path; first-touch attribution is now caught up and the reporting reflects the recovered data. First-touch data older than 7 days is not recoverable — the underlying pageviews simply weren’t there to replay. In practice 365-day first-touch only matters for cohorts that span more than 7 days of dormant visitor return, so most workspaces will see no functional gap. If your store relies on first-touch attribution for cohorts longer than 7 days (e.g. quarterly cohort LTV reports), expect slightly lower match rates for visitors whose first touch fell inside the loss window — those will fall back to last-click only.

The Pixel Events This Period number is correct from the moment the hourly recalculation’s first run completes — no replay needed, because it’s recalculated directly from your real event traffic.

How to verify your data is now flowing

1. Confirm pageviews are growing. Open /marketing-acquisition. The pageview total at the top of the page should advance as your store gets traffic. If it’s flat for >30 minutes during business hours, the pixel itself is the issue (see CSP errors blocking the pixel).
2. Confirm source breakdown is non-empty. Open /dashboard/analytics and scroll to the Acquisition card. You should see UTM sources for any campaigns running this week (google / facebook / klaviyo / direct / etc.). Returning-visitor rows from the loss window will fall back to last-click; new visitors from this week onward will show full first-touch.
3. Confirm the events counter is populating. Open /billing. The Pixel Events This Period tile should show a non-zero number that matches your actual event traffic. The recalculation runs hourly — if you just upgraded, allow up to 60 minutes for the first run to complete.
4. Confirm your billing details look right. Your billing page should reflect the correct plan, usage, and renewal date. If anything looks off after the steps above, email support@admaxxer.com — our team continuously monitors the Stripe integration and can confirm everything is healthy on your account.

If any step still shows the bug-era symptom, the page Missing orders walks through the deeper causes (pixel install, consent blocking, webhook lag) that can produce a similar empty-data look.

FAQ

Was my data lost forever?

Pageviews, sessions, payments, and goal events were never lost — those are recorded separately and weren't affected by the bug. The narrow loss was on first-touch attribution: the records that should have saved between 2026-04-29 and 2026-05-05 were rejected instead. We backfilled the last 7 days of first-touch details (UTMs + referrer + landing path) by replaying every pageview in that window through the now-fixed path. First-touch data older than 7 days is not recoverable, but in practice 365-day first-touch only matters for cohorts that span more than 7 days of dormant visitor return — most workspaces will see no functional gap.

Why did my billing page show `0` events used?

The events-used count was being shown on the billing page and the internal admin view, but nothing was ever updating it behind the scenes. In effect it had become a display-only number that nobody was keeping current. We've shipped an hourly job that recalculates the true count from your real event traffic and refreshes the number, plus an automated build check that blocks any future shipping of a similar display value that's shown but never updated. Your billing page now reflects real usage within an hour of any traffic change.

Did this affect my plan limits or trigger over-quota throttling?

No. The events-used number on the billing page was display-only — quota enforcement runs on a completely separate path that always read your real usage directly, so it was correct the whole time. The bug only affected the `Pixel Events This Period` tile on /billing and the internal usage view. Nobody was throttled because of the stale number.

How was the first-touch ingest bug not caught at deploy time?

The credential the first-touch attribution writer used had a permission gap that only showed up under production conditions — in the development environment it happened to work, so the failure stayed hidden until the live deploy. This is the same shape as GL#363 (a feature shipped but the wiring resolved to the wrong place). We've added an automated build check that confirms every analytics write has the right permissions for its destination, so this exact failure mode can't recur silently.

What's the Stripe migration error and how is it related?

Unrelated to the attribution bug, but bundled into the same ship. Every boot was logging a harmless Stripe-related error because a database setup step had been applied in the wrong order — a piece of structure was being referenced before the step that created it had run. Customer-facing impact was zero (our Stripe sync recovers automatically), but it cluttered the logs and made it harder to spot real Stripe errors. We've corrected the ordering with a safe, re-runnable fix and added an internal health check that flags it immediately if any required Stripe setup is ever missing again.

Next steps

• Attribution discrepancies — if your numbers disagree with Meta or Google by more than 20%, this is the reconciliation methodology.
• Sales mismatch (revenue) — if your Shopify total revenue disagrees with Admaxxer’s revenue card.
• Missing orders — if Admaxxer is missing entire orders that exist in Shopify.
• Back to Documentation