Decide whether GA4’s new event transport belongs in your offline lead system

Google’s GA4 release notes describe the Data Manager API as an alternative for sending non-reserved recommended and custom events to Analytics web and app streams. The upgrade guide positions it as a unified model across supported Google destinations, with OAuth, optional field-specific encryption support, multiple destinations, and fast-fail behavior. Measurement Protocol remains GA-specific, uses a measurement ID and API secret, and sends to one stream per request. Those are transport and governance differences, not a new definition of a lead.

This transport assumes the lead architecture described in the existing attribution guide: a governed operational record, one durable lead ID, explicit status definitions, permitted identifiers, and an audit trail. Analytics can receive observations about those transitions, but it must not become the system that decides them. The Data Manager preflight is therefore narrow: confirm which source status creates which event, which timestamp and identifier travel with it, and which records must remain unmatched or suppressed.

Google’s recommended lead events include generate_lead, qualify_lead, disqualify_lead, working_lead, close_convert_lead, and close_unconvert_lead. Those names are useful only if the business writes its own inclusion rule. A booked estimate might be “qualified” for one company and merely “working” for another. A closed-converted event might mean signed contract, collected deposit, or completed job. Choose one definition, document it beside the source field, and prevent vendors or sales users from changing it casually.

Govern value and status semantics as carefully as event names. Define whether value means quoted amount, expected value, collected revenue, or another unit; send currency whenever a monetary value is sent; preserve lead source as an operational field rather than overwriting platform attribution; and version disqualification or lost-reason categories. GA4’s lead reports can count users associated with lead-stage events. They are not an operational ledger of unique inquiries, opportunities, jobs, or revenue.

The API cannot join an offline update to a digital journey if the required connection was never captured. Google’s Analytics event examples require a client ID for ordinary web-stream cases, with documented alternatives or additional identifiers for some transaction and advertising-source scenarios; app streams use an app instance ID. A user ID can help only when it represents an authenticated identity under the property’s configured rules. Advertising identifiers have their own consent and product constraints. Do not synthesize a client ID, copy one lead’s identifier to another, or force unmatched records into direct traffic.

Retries create a second risk: one CRM transition can become multiple analytics events. transactionId has documented matching and event-specific roles; it is not a universal offline-lead idempotency key. Build an internal delivery key from stable lead ID, versioned event definition, transition identity, and destination. Store request fingerprint, requestId when returned, response, attempt count, and final disposition. Internal idempotency prevents the sender from deliberately duplicating work, but it cannot guarantee GA exactly-once delivery after an ambiguous network result. Preserve UNKNOWN_AFTER_SEND until destination evidence or a governed recovery rule resolves it.

Offline service outcomes arrive late. As documented July 18, 2026, eventTimestamp for every Google Analytics event sent through this API must be within 72 hours of the request. The 48-hour rule is narrower: an additional-data-source event meant to join an original gtag or Firebase event must arrive within 48 hours of that original event's timestamp. Recheck both rules before build.

A later event can be accepted without recreating the original session or attribution context an analyst expects. Treat transport acceptance, join eligibility, reporting attribution, and business truth as separate states. Never promise that a timely offline event will inherit a particular acquisition source or session merely because an identifier is present.

Do not falsify a recent timestamp to force an old outcome through an acceptance window. That turns a late operational observation into a misleading measurement event. Instead, classify the record: eligible and timely, eligible but unmatched, too old for this transport, blocked by consent, invalid mapping, or temporary delivery failure. Keep the full outcome in the CRM regardless of Analytics delivery. If the business needs longer-lag conversion feedback for advertising, evaluate the destination-specific offline conversion product and its current rules rather than assuming GA4 event transport is interchangeable.

Keep the business mapping separate from the Google request client. One component should turn a governed lead transition into a destination-neutral event envelope. Another should select the GA architecture, validate requirements, encrypt only fields and destinations for which current documentation supports or requires transformation, authenticate, build destinations, send, and normalize the response. Encryption is not a blanket wrapper around every GA payload. This boundary lets mapping tests run without network calls and supports a controlled comparison with Measurement Protocol.

Validation has three levels. Contract tests prove fields, types, event names, timestamps, architecture, and identifiers. A validateOnly request can prove request validation without proving delivery or generating delivery diagnostics. End-to-end tests in a controlled property prove a known CRM record becomes an expected Analytics observation. A successful HTTP response proves request acceptance, not accurate reporting or attribution. Preserve requestId, diagnostics, timestamps, retries, UNKNOWN_AFTER_SEND, and dead-letter dispositions.

A migration pilot should compare transports without sending duplicate production semantics into the same property. Use a test property, a validation-only path, or a mutually exclusive cohort approved by the measurement owner. Do not send the same ordinary event through two paths in parallel unless that specific event has a documented, tested destination deduplication contract. Matching transaction identifiers do not universally deduplicate every event type, parameter, report, or downstream export.

Measure the pilot as an operational system: eligible source transitions, suppressed records by reason, accepted requests, rejected requests by error class, unknown-after-send records, retry recovery, unmatched records, observed destination events, and reconciliation lag. Google diagnostics can return aggregate warning or error counts by reason and may not identify every failed source record, so use one record or small homogeneous batches when record-level diagnosis matters. Keep internal state, request diagnostics, destination observation, and CRM truth separate.

For a greenfield governed integration, Data Manager API is the current default candidate because Google positions it as the upgrade path and unified event model. For an existing stable GA-only Measurement Protocol integration, migration is optional until the pilot shows a concrete advantage. Different approved transports can coexist when semantics and owners are explicit. What matters is that one operational event is not quietly multiplied into several analytics claims and every delivered event remains subordinate to the lead record.

Poll delivery diagnostics on an operational cadence appropriate to request volume and retry risk; do not wait for a monthly business review to discover transport errors. Reconcile source transitions, destination observations, and business outcomes on a separate daily, weekly, or monthly cadence. For a newly created conversion that will inform Google Ads bidding, current documentation describes an initial 14-day reporting-only trial before it becomes biddable. Version mappings and annotate dashboards at each material release.