From 8951e38bd31f993e77032a2a25240f64c94eb61f Mon Sep 17 00:00:00 2001 From: Darshil Rathod <69842641+RathodDarshil@users.noreply.github.com> Date: Fri, 24 Jul 2026 18:21:12 +0530 Subject: [PATCH 1/2] docs: Event Date vs Install Date reporting views (LIN-2101) New features/reporting-time page documenting the Report by toggle: the two date bases, which metrics change, where the toggle applies, cohort maturity behavior on recent days, and remaining ad-network reconciliation gaps. Adds the reporting query parameter to the Reporting API page. --- api-reference/reporting-campaigns.mdx | 1 + docs.json | 1 + features/reporting-time.mdx | 79 +++++++++++++++++++++++++++ 3 files changed, 81 insertions(+) create mode 100644 features/reporting-time.mdx diff --git a/api-reference/reporting-campaigns.mdx b/api-reference/reporting-campaigns.mdx index ddb2452..a6c9724 100644 --- a/api-reference/reporting-campaigns.mdx +++ b/api-reference/reporting-campaigns.mdx @@ -98,6 +98,7 @@ Numeric fields are returned as **formatted strings** (`"3,201"`, `"$12,540.50"`) | `platform` | string | (both) | `ios` or `android`. | | `search` | string | (none) | Matches name, display ID, domain, deeplink, or full tracking URL. | | `view` | string | `user_acquisition` | `user_acquisition` (new users: `installs`, `cost_per_install`) or `retargeting` (re-engaged users: `reinstalls`, `reengagements`, `cost_per_reinstall`). | +| `reporting` | string | `event_date` | `event_date` (conversions counted on the date they happened) or `install_date` (counted on the install date of the user, matching Google and Meta reporting). See [Event Date vs Install Date Reporting](/features/reporting-time). | | `sort_field` | string | `installs` | `clicks`, `installs`, `signups`, `revenue`, `spend`, `created_at`, `uninstalls`, `conversion`, `suspicious_installs`, `roas`. | | `sort_order` | string | `descending` | `ascending` or `descending`. | | `page` | number | `1` | 1-indexed. | diff --git a/docs.json b/docs.json index fa2f5da..66ca395 100644 --- a/docs.json +++ b/docs.json @@ -69,6 +69,7 @@ "features/custom-store-listing", "features/uninstall-tracking", "features/retention", + "features/reporting-time", "features/meta-install-referrer", "features/ios-campaign-data-limitations", "features/webhooks", diff --git a/features/reporting-time.mdx b/features/reporting-time.mdx new file mode 100644 index 0000000..1ee6a49 --- /dev/null +++ b/features/reporting-time.mdx @@ -0,0 +1,79 @@ +--- +title: "Event Date vs Install Date Reporting" +description: "Choose whether conversions are counted on the date they happened or on the install date of the user, to align Linkrunner with Google and Meta ads reporting." +icon: "calendar-days" +sidebarTitle: "Reporting Time" +--- + +Linkrunner can report post-install conversions (sign ups, custom events, payment events, and revenue) on two different date bases. Use the **Report by** toggle on the campaigns page to switch between them. + +## The two views + +### Event Date (default) + +Conversions are counted on the date they actually happened. A purchase made on July 10 by a user who installed on July 2 appears on July 10. + +This is the traditional MMP "activity" view. It answers: "what happened in my app on this day?" + +### Install Date + +Conversions are counted on the install date of the user who converted. The same July 10 purchase from a July 2 install appears on July 2. + +This matches how Google Ads and Meta report conversions: both attribute a conversion back to the date of the ad interaction, not the date the conversion happened. If you compare Linkrunner against your ads dashboards, use this view. It answers: "what did the users I acquired on this day eventually do?" + + +Other MMPs offer the same concept under different names: AppsFlyer calls it LTV data (their Overview dashboard default), Adjust calls it cohort metrics, and Branch calls it Cohorts. In Linkrunner it is a toggle on the same reports rather than a separate report. + + +## What changes between the views + +| Metric | Event Date | Install Date | +| --- | --- | --- | +| Sign Ups | Date of the sign up | Install date of the user | +| Custom events | Date of the event | Install date of the user | +| Payment events and Revenue | Date of the payment | Install date of the paying user | +| CR, ROAS, cost per event | Derived from event-dated conversions | Derived from install-dated conversions (cohort based, like ad networks) | + +These are unchanged in both views, because they are already dated by the install or ad interaction itself: + +- Clicks, Impressions, Installs, Spend, CPI +- Retention and uninstalls +- Active users + +Totals over all time are identical in both views. Switching only changes which day a conversion is counted on, never whether it is counted. + +## Where the toggle applies + +Switching **Report by** on the campaigns page updates everything on it together: + +- The campaign table, totals row, and Organic row +- The campaign details drawer: metric cards, chart, and the user list +- The Overview panel (current month numbers and trends) +- Exports started from the page: campaign CSV export and the **All Onboarded Users** / **Paying Users** downloads +- The [Reporting API](/api-reference/reporting-campaigns) via the `reporting` query parameter + +## Recent days look lower in Install Date view + +A cohort keeps generating conversions for days or weeks after install. In Install Date view, recent install dates have not had time to convert yet, so their numbers start low and grow as conversions arrive. Yesterday's revenue in this view is not final; it will keep increasing. + +This is the same behavior you see in Google and Meta dashboards, and it is the main reason those dashboards "restate" past days. + + +When comparing against an ads dashboard, use a closed window that ended at least a week ago, so both sides have had time to mature. + + +## Why numbers still may not match ad networks exactly + +Install Date view removes the date-shift discrepancy, which is usually the largest one. Remaining differences come from: + +- **Modeled and view-through conversions.** Meta includes modeled conversions and view-through attribution that no MMP observes directly. +- **Attribution windows.** The network's click-through and view-through windows may differ from your Linkrunner conversion windows. +- **Timezones.** Compare using the same timezone on both sides. Linkrunner uses your project timezone. + +## Troubleshooting + +- **Numbers changed after switching the toggle.** Expected. The two views distribute the same conversions across different days. +- **Yesterday's revenue in Install Date view is lower than Event Date view.** Expected. Recent cohorts have not finished converting. The gap closes over time. +- **All-time totals differ between views.** They should not. If you see this with no date filter applied, contact support. + +**Need help?** Contact [support@linkrunner.io](mailto:support@linkrunner.io) From 1d15ca0d2824b28869268967891ad2ba5227bf4e Mon Sep 17 00:00:00 2001 From: Darshil Rathod <69842641+RathodDarshil@users.noreply.github.com> Date: Fri, 24 Jul 2026 20:33:31 +0530 Subject: [PATCH 2/2] docs: Retargeting view always uses Event Date (LIN-2101 validation) Adds a section explaining why Install Date is disabled in the Retargeting view: networks date retargeting conversions to the re-engagement interaction (= event date), matching AppsFlyer/Adjust conventions of anchoring retargeting cohorts to re-engagement/reattribution date. Scopes the Google/ Meta alignment claim to user-acquisition conversions and adds the practical pairing rule (UA -> Install Date, Retargeting -> Event Date). --- features/reporting-time.mdx | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/features/reporting-time.mdx b/features/reporting-time.mdx index 1ee6a49..8eb7229 100644 --- a/features/reporting-time.mdx +++ b/features/reporting-time.mdx @@ -19,7 +19,7 @@ This is the traditional MMP "activity" view. It answers: "what happened in my ap Conversions are counted on the install date of the user who converted. The same July 10 purchase from a July 2 install appears on July 2. -This matches how Google Ads and Meta report conversions: both attribute a conversion back to the date of the ad interaction, not the date the conversion happened. If you compare Linkrunner against your ads dashboards, use this view. It answers: "what did the users I acquired on this day eventually do?" +This matches how Google Ads and Meta report user-acquisition conversions: both attribute a conversion back to the date of the ad interaction, not the date the conversion happened. For UA campaigns the ad interaction is the click that drove the install, so Install Date is the closest equivalent. If you compare Linkrunner UA numbers against your ads dashboards, use this view. It answers: "what did the users I acquired on this day eventually do?" Other MMPs offer the same concept under different names: AppsFlyer calls it LTV data (their Overview dashboard default), Adjust calls it cohort metrics, and Branch calls it Cohorts. In Linkrunner it is a toggle on the same reports rather than a separate report. @@ -42,6 +42,18 @@ These are unchanged in both views, because they are already dated by the install Totals over all time are identical in both views. Switching only changes which day a conversion is counted on, never whether it is counted. +## Retargeting view always uses Event Date + +The Install Date option is disabled while the campaigns page is in the **Retargeting** view, and the page reports by Event Date there. + +This is intentional. Retargeting conversions are credited to the re-engagement, and ad networks date them to that recent ad interaction. A user who installed in January and was re-engaged by a retargeting ad in July shows up in Meta and Google on the July interaction date, which is (almost always) the date of the conversion itself: the Event Date. Re-dating that conversion to the January install would move it outside the retargeting campaign's own lifetime and away from every network's reporting. + +AppsFlyer and Adjust follow the same convention: their retargeting cohorts are anchored to the re-engagement or reattribution date, never the user's original install date. + + +Practical rule for reconciling with ads dashboards: compare UA campaigns using Install Date, and retargeting campaigns using Event Date. Linkrunner's view switcher and Report by toggle enforce this pairing automatically. + + ## Where the toggle applies Switching **Report by** on the campaigns page updates everything on it together: @@ -75,5 +87,6 @@ Install Date view removes the date-shift discrepancy, which is usually the large - **Numbers changed after switching the toggle.** Expected. The two views distribute the same conversions across different days. - **Yesterday's revenue in Install Date view is lower than Event Date view.** Expected. Recent cohorts have not finished converting. The gap closes over time. - **All-time totals differ between views.** They should not. If you see this with no date filter applied, contact support. +- **The Install Date option is disabled.** You are in the Retargeting view, which always reports by Event Date (see above). **Need help?** Contact [support@linkrunner.io](mailto:support@linkrunner.io)