Hi — Managed Warehouse question. A client-side bug...
# ask-questionsp
prehistoric-potato-57414
08/14/2026, 12:06 AMHi — Managed Warehouse question. A client-side bug on our end logged ~20h of experiment exposures under the wrong identity, so 25 real conversions can't join in two running experiments (exp_19g6nmsqh79oh, exp_19g6mmsqioq9f, client key sdk-1teSpof7e91VV60). We reconstructed the missing events exactly and tried to backfill via POST us1.gb-ingest.com/track using the documented batched format (sentAt + per-event timestamp) — every attempt returns HTTP 200 but the rows never become queryable, while live SDK/server events on the same key ingest fine. Is there per-row validation we can't see, or can someone insert a 50-event payload for us? Happy to DM or email the exact JSON. This is client-facing launch reporting, so speed is appreciated.
f
fresh-football-47124
08/14/2026, 12:07 AM
I dont think we do any special validation
fresh-football-47124
08/14/2026, 12:08 AM
can you see them with the sql explorer in the product analytics?
🙌 1
p
prehistoric-potato-57414
08/14/2026, 12:31 AMGood call - found it with the SQL explorer. The data is all there and this looks like working-as-designed colliding with our repair. The backfilled exposures landed in experiment_views with the correct arms and back-dated timestamps, and the order events are in events. But the analysis's fact query shows a "__multiple__" bucket: many of the rescued devices also have post-repair real exposures, and since the identity fix re-randomized them, some landed in a different variation than their backfilled arm — so the analysis excludes them as multi-variation units.
Question: is there any way to have the analysis keep the FIRST exposure per unit instead of excluding conflicts, or to suppress specific exposure rows?
prehistoric-potato-57414
08/14/2026, 12:38 AMFollow-up — disregard my last message, the "__multiple__" theory was wrong (that bucket turned out to be a handful of organic multi-exposure devices, not our backfill). The real cause was entirely on our side: the experiment was configured with a stale metric that keys on a client-side pixel event instead of our server-side order event, so the analysis was reading the wrong event the whole time — ingestion, the exposures, and your runner were all fine. Spotted it in the rendered fact query via View Queries: the metric's CASE was matching a different event_name than the one our orders emit. Swapped the experiments onto the right metric IDs and everything reconciles. The SQL explorer pointer is what cracked it — thanks, and sorry for the noise.
f
fresh-football-47124
08/14/2026, 1:41 AM
no problem, glad you got it sorted
3 Views