An onboarding event QA checklist before you trust the funnel

Trace one known journey end to end

Start with a test installation and a short expected sequence: start, visible screen, next action, completion. Record the application, flow/release version, event names and expected order. Compare that plan with what the app sends and what the server accepts.

Use a disposable development scope rather than adding synthetic events to real customer reports. A screenshot of a plausible funnel is not a validation of ingestion. You need evidence that the intended events arrive once, with the intended identifiers, and stay within the correct application.

Check what triggers an exposure

Configuration download, screen construction and actual presentation can occur at different times. Record exposure at the defined visible point. An event emitted while a screen is still hidden can make the funnel look healthier than the user experience.

For completion, verify the destination rather than a button tap that can fail. Test repeated taps, back navigation and restored sessions. Document whether revisiting a screen creates another raw event and how the installation-level metric deduplicates it.

Verify identity and scope on every path

Confirm that an installation keeps its identity across normal restarts, and document what happens after reinstall or data reset. If account sign-in is involved, keep installation and user semantics separate. Combining them halfway through an analysis changes the unit being counted.

Inspect organization and application boundaries server-side, including denied requests. Changing an app selector must not leave previous-app data in the report. A correct event name does not make an event valid for a different application or store configuration.

• Expected app and organization match the authenticated scope.
• Event IDs are stable for retries and distinct for new events.
• Release/experiment context matches the rendered experience.
• No raw credentials or unnecessary personal answers appear in payloads.

Rehearse lost responses and late delivery

Send a test batch, simulate losing the acknowledgement and retry the same event identifiers. The final report should not double-count the known journey. Separately test malformed payloads and revoked credentials so a permanent error is not retried indefinitely as a transient outage.

For offline events, preserve occurrence time and inspect receipt time separately. Reconcile them to the original cohort under a stated policy. Consent revocation must prevent prohibited collection or later resend; verify this after restart as well as in the current session.

Use a small evidence sheet for release review

For each scenario, record the expected event count, actual accepted count, scope, result and any limitation. Include a fresh installation, a repeated screen, a retry, an offline completion and a denied request. Keep the test data and environment clearly labeled.

Only after these checks should a drop-off become a product investigation. Missing telemetry, a changed schema or a transport failure can mimic abandonment. Aplyna’s event reference describes the supported contract; your integration still needs verification in the actual shipped native app.