Mobile Analytics Integration Strategy

What this prompt does

This prompt designs a full mobile analytics strategy and the code abstraction to keep it clean. It runs through six steps: defining an event taxonomy, building a provider-agnostic analytics abstraction, setting up user identity and properties, implementing conversion funnels, configuring cohort retention analysis, and enforcing privacy compliance. The order matters because a messy taxonomy and provider lock-in are the failures that hurt later, long after launch.

The variables shape the plan to your product. [naming_convention] and [event_count] define the tracking plan, [business_events] capture domain-specific actions, and [primary_provider] plus [secondary_provider] are wired behind one AnalyticsService interface. [identity_method] and [user_tiers] drive identity resolution, [funnel_count] and [conversion_threshold] define funnels and alerts, [cohort_dimension] and [retention_definition] shape retention, and [privacy_frameworks] set the consent rules. The abstraction is the part that turns a provider swap into a one-file change, which is why it is built before any provider-specific code lands. Getting the taxonomy and the abstraction right early is far cheaper than untangling a tag soup of provider calls scattered through the app after launch.

When to use it

• You are instrumenting a new mobile app and want a consistent event taxonomy from day one.
• You want to avoid analytics-provider lock-in by routing through one abstraction.
• You need identity resolution that survives login, logout, and reinstalls.
• You want conversion funnels with drop-off alerts, not just raw event counts.
• You need cohort retention reporting (D1, D7, D30, D90) tied to a real active-session definition.
• You must satisfy GDPR, CCPA, and ATT before launch rather than patching consent afterward.

Example output

Expect a tracking plan covering [event_count] events grouped into screen views, user actions, system events, and business events, with required and optional properties per event. Alongside that you get an AnalyticsService interface with adapters for [primary_provider] and [secondary_provider], an identity flow handling anonymous-to-authenticated merges, [funnel_count] funnel definitions with drop-off points, cohort retention reports by [cohort_dimension], and a consent-management design for [privacy_frameworks] with granular categories. It is largely architecture and spreadsheet-style planning plus interface code, organized so that each layer can be reviewed and implemented independently.

Pro tips

• Lock [naming_convention] early; an object_action style applied consistently across all [event_count] events saves painful renames later.
• Define [business_events] carefully, since these are what funnels and retention ultimately measure.
• Keep the AnalyticsService abstraction strict so swapping [primary_provider] or [secondary_provider] stays a one-file change.
• Set [retention_definition] to something meaningful for your app; counting any app open as active inflates retention misleadingly.
• Make consent gating real: block tracking until opt-in and honor [privacy_frameworks] signals like ATT before any event fires.
• Tune [conversion_threshold] to your baseline so drop-off alerts are actionable rather than noisy and easy to ignore.