I85PREP
⌘ K
Adobe Analytics Business Practitioner Expert study materials
Adobe Analytics Business Practitioner Expert study resources

The Report Suite That Counts Twice

Adobe Analytics Business Practitioner Expert · Put your knowledge to work in context.

All case studies

The Report Suite That Counts Twice

A retail client has one global report suite and a separate mobile app report suite. They want a unified view of a customer who browses on mobile web, then buys in the app. You propose an implementation where the mobile web and app both send data to the global report suite using an AppMeasurement library plus the mobile SDK, with a shared visitor ID passed via a custom variable. The client's analyst reports that the global suite's unique visitors are 18% higher than the sum of the two source suites, and that product views are inflated on pages where a recommendation widget loads. The client also wants to know why the mobile app's "purchase" events are not appearing in the global suite even though the app team says they fire the event.

1. Diagnose the inflated unique visitors and the inflated product views. What implementation facts would you verify?

Read the worked answer

Inflated unique visitors (18% over the sum): Two likely causes, both verifiable.

  1. Visitor ID stitching failure. If the shared visitor ID custom variable is not set on every hit (e.g., only set after login, or lost on the app's first launch), the same person is counted as two visitors. Check the custom variable's participation rate - if it is below 100% of hits, stitching is incomplete.
  2. Different visitor-ID methods across libraries. AppMeasurement and the mobile SDK may use different default visitor identification, so a person who is anonymous on web and anonymous in the app is two visitors. Confirm whether the client is using Experience Cloud ID Service consistently and whether the app passes the same ECID.

Inflated product views: The recommendation widget almost certainly fires a product-view event on every render, including re-renders and lazy-loaded carousels. Verify by checking the event's trigger condition in the tag rule and by comparing product-view counts to page-view counts on affected pages. A single page generating multiple product views per product is the signature.

Method: Compare the global suite's visitor count to a de-duplicated count using the shared ID, and pull a hit-level breakdown of product-view events by page to confirm the widget's multiplier.

2. The app's purchase events are missing from the global suite. What are the plausible causes, and how do you isolate the right one?

Read the worked answer

Plausible causes, ordered by likelihood:

  1. Event not enabled in the global suite. The app team fires an event that exists in the app suite but was never enabled in the global suite's success events. Check the global suite's event configuration against the app's.
  2. Wrong report suite ID in the app's configuration. The app may still be pointed at the app suite, or the global suite ID was entered incorrectly. Check the SDK configuration.
  3. Event name mismatch. The app sends purchase but the global suite expects purchase_complete (or the event is mapped differently in processing rules). Check the raw event values.
  4. Processing rule or VISTA filtering it out in the global suite.

Isolation method: Use a real-time or debug/trace view on the global suite while triggering a test purchase in the app. If the hit never arrives, it is a configuration or routing problem (causes 2–4). If the hit arrives but the event is not recorded, it is an event-enablement problem (cause 1). This single test separates the two families of causes before you touch any settings.