Analytics & Attribution
Your Server Event Arrived. GA4 Still May Not Know Where It Came From.
Updated: October 2026
A GA4 Measurement Protocol event can be accepted and still appear without useful session attribution. To connect a server event to the right journey, send the correct client or app identifier, a valid session_id, an accurate timestamp, consent state, and deduplication logic—then validate before trusting reports.
Delivery is not attribution
The Measurement Protocol sends events with an HTTP request. A successful response confirms receipt, not that every parameter is valid or that the event will join the intended session. Google warns that session-based events can show (not set)/(not set) for source and medium when a valid session_id is missing.
This matters for offline lead updates, payments, refunds, subscriptions, calls, and CRM events. The event can increase a key-event total while weakening channel analysis.
The attribution contract
| Control | Purpose | Failure |
|---|---|---|
| client_id or app_instance_id | User context | Cannot join expected journey |
| session_id | Session association | Source/medium becomes not set |
| timestamp_micros | Correct event time | Misleading journey order |
| event_id / transaction_id | Deduplication | Duplicate conversions |
| consent | Applicable privacy state | Privacy and modeling inconsistency |
A validation workflow
Capture identifiers at the source
Store the GA client or app identifier and current session ID with the lead, cart, or transaction that later triggers the server event. Do not reconstruct them from email or CRM identity.
Use the validation endpoint
Use Google’s validation server or Event Builder in development. Treat warnings as defects even when the production endpoint would accept the payload.
Control event time
Send when the business action occurred. Google documents backdating behavior, including a 72-hour window in many cases. Do not convert delayed CRM processing time into conversion time.
Prevent duplicates
Retries are normal. Generate stable identifiers so the same payment or qualified-lead update is not counted twice.
Reconcile three systems
The source proves the business event, transport logs prove the request, and GA4 proves reporting. A discrepancy should be diagnosable to one layer.
Post-launch checks
- Share of server events with a session source and medium.
- Event timestamps versus CRM or payment time.
- Transaction IDs across retries.
- Attributed totals versus the source system.
- Consent state alignment.
- Unexpected channel-mix changes.
Use the GA4 Consent Mode diagnostics guide when consent is the likely break, and the offline conversion lag framework for delayed outcomes.
Monitor an attribution-quality rate
Create a diagnostic ratio: server events with a valid session source and medium divided by all eligible server events. Break it down by event name, platform, implementation version, and day. A sudden drop usually points to an identifier, consent, or timing regression even when total event volume looks stable.
Keep this diagnostic separate from conversion performance. A lower unattributed rate improves analysis, but it does not prove the marketing program created more conversions. Measurement quality and business lift answer different questions.
Frequently asked questions
Does HTTP 2xx mean the event is correct?
No. It means the request was received. Validate the payload and resulting dimensions.
Can attribution work without session_id?
The event may appear, but Google notes that session source and medium can become not set.
Should Measurement Protocol replace browser tagging?
Usually no. Google describes it as a way to augment existing collection.