[RUM] Reo.dev intent pixel: 90% of event POSTs rejected 400 for 30+ days, on 66% of sessions

[dawsontoth]

Summary

The embedded Reo.dev intent pixel rejects roughly 90% of the events it posts, and has done so for at least 30 days. In the last 24h: 1,105 × POST https://aplo-evnt.com/api/v1/intent_pixel/track_request returned HTTP 400, against only 116 × 200 on the same host — a 90.6% failure rate — touching 102 of 154 sessions (66%).

Nothing in Studio's error stream shows this, which is why it has gone unreported: shouldKeepEvent deliberately drops errors originating in the Reo bundle (THIRD_PARTY_SCRIPT_FRAME), and a 4xx resource response never produces a JS error in the first place. The only place it is visible is the RUM resource stream.

Surfaced by the automated daily RUM review (app f590deee-…).

Datadog findings

@type:resource @resource.url_host:aplo-evnt.com

Window	400	200	% 400	Sessions w/ 400s	Total sessions
24h → now	1105–1118	116	90.6%	102	154
48h → 24h ago	934	104	89.7%	87	127
7d → 48h ago	2587	324	84.9%	321	521
14d → 7d ago	6643	558	90.8%	—	—
30d → 14d ago	885	102	87.6%	—	—

• Endpoint: a single one — POST /api/v1/intent_pixel/track_request, @resource.type:fetch.
• Not new, and not a spike. The failure ratio has sat at 85–91% across every window back to 30 days. This is a steady-state condition, not a regression.
• Server-side rejection, not a blocked request. Mean response time 188ms with a real 400 status. An ad-blocked or firewalled beacon would surface as a network error, not as an HTTP 400 — something is answering and refusing the payload.
• Reach is broad, not concentrated: ~2/3 of all sessions in every window (66%, 69%, 62%), so this is not one bad client or one bad browser.

Why this is worth fixing

Two costs, neither of them user-visible — which is exactly why it needs filing rather than watching:

1. The analytics data is largely not landing. If ~90% of intent-pixel events are refused, any funnel or intent reporting built on Reo is being drawn from roughly a tenth of the traffic. Whatever decisions rest on that data are resting on a biased sample of unknown shape.
2. ~1,100 pointless POSTs/day run in customers' browsers, each ~188ms, on two thirds of sessions.

Where it comes from

Studio's own involvement is three lines — src/integrations/reo/reo.ts loads the vendor bundle and hands it a client ID:

loadReoScript({ clientID: import.meta.env.VITE_REO_DEV_CLIENT_ID })
	.then((Reo) => {
		Reo?.init?.({ clientID: import.meta.env.VITE_REO_DEV_CLIENT_ID });
		return reoClient = Reo;
	});

The failing request is issued from inside the vendor's bundle, so RUM cannot see the request body and we cannot see which field it dislikes. Note aplo-evnt.com is Reo's event host — distinct from api.reo.dev, which separately returned 5 × 400 in the same window.

We are already on the latest release. reodotdev is pinned ^1.0.0 and resolves to 1.1.0, which is the newest version published (1.0.0, 1.0.1, 1.1.0). So there is no upgrade to take.

Suggested next steps

1. Reproduce locally with a valid VITE_REO_DEV_CLIENT_ID and read the 400's response body in devtools — that is the one piece of information RUM structurally cannot provide, and it likely names the rejected field.
2. Confirm the production VITE_REO_DEV_CLIENT_ID is the right ID for the current Reo account/plan. A stale or wrong-environment client ID rejected at the ingest boundary would produce exactly this shape: uniform, fast, near-total 400s.
3. If the ID is correct, this is a vendor-side ingest bug — worth raising with Reo support, with the endpoint and ratio above.
4. If Reo is not actively used, consider dropping the integration; it is currently pure cost.

Notes / limitations

• No customer identifiers, emails, hostnames, org or instance IDs are included here.
• RUM cannot see request or response bodies, so the reason for the 400 is not directly observable — hence step 1 above rather than a root cause.