DashThis With Causality Engine: Read the Merged Conversions

The short answer: a DashThis report can be correct on the day it is emailed and different two weeks later, and still add up to more orders than the store took. DashThis, the reporting tool that turns marketing platforms into branded client dashboards, applies Meta's own default of 7-day click and 1-day view to every conversion widget unless you change it (Meta comparison article), and conversions that arrive after the period closes reach the dashboard only when the widget is refreshed (latent conversions article). Those are Meta's numbers, faithfully copied. For what each channel caused, Causality Engine, which reads the store's GA4 export rather than any platform, gives a free first finding on its start page.

Disclosure: I founded Causality Engine and own it, and this page recommends it. Every claim about it links to Causality Engine's own pages.

Three things to check before the 1st of the month:

• The overlap, as a sum. For example, 486 Meta purchases, 412 Google Ads conversions and 71 Bing Ads conversions are 486 + 412 + 71 = 969 orders claimed. Against 861 Shopify orders, that is 969 - 861 = 108 orders that two or more platforms are counting together.
• The Shopify widget already on the dashboard. Total Orders is defined as the total number of orders received (Shopify metrics). It is the only figure in the report that no ad platform scored.
• The empty dropdown. Edit a Meta widget: if the attribution field shows no value, Meta's default is in force (Meta comparison article).

What DashThis shows and what the read shows

The window DashThis borrows from Meta

DashThis does not decide when an ad earns a sale. Its attribution settings article says it applies each campaign's own window to that campaign, and that an account-level window, where one exists, overrides the campaign settings. The aim stated there is that DashThis shows the same data as the Meta account. Only widgets with conversion metrics are affected.

The Meta comparison article gives the default as 7-day click and 1-day view, and warns that data can vary a lot when that setting changes. A view counts: someone who saw an ad and bought within a day without clicking is a Meta purchase. The filter called Action Attribution Window lets you pick other windows per widget.

Then there is timing. The latent conversions article explains that paid platforms keep adding conversions to a closed period as late buyers convert, so the last completed period should be refreshed by hand. Google Ads refreshes on its own when the dashboard opens. The others wait for you. A PDF sent on the 1st freezes whichever figure existed that morning.

Merging and calculating: the arithmetic DashThis allows

Two features put platforms in one figure.

A merge joins widgets of the same graph type. The merge article lists combining "similar but not exactly the same data" as a reason to merge, with Google Ads Conversions plus Google Ads Purchases as the example, and says a merge cannot be undone. If purchase is already one of the conversion actions counted in Conversions, that merge counts it twice; check the action list in Google Ads before you merge.

A Calculated Widget goes further. The calculated widget article shows formulas across integrations, such as total ad spend, and suggests a pie chart with Integration as the dimension, one slice per platform. Spend divides cleanly into slices. Conversions do not, because the slices are claims that overlap, and a pie implies parts of one whole.

GA4 rows the platforms never see

GA4 widgets carry a different kind of trap. DashThis's GA4 comparison article says sessions GA4 cannot attribute land under (not set) or (direct) / (none), and a sum of named sources leaves them out. It also separates session-scoped Session source / medium from user-scoped First user source / medium; mixing scopes will not add up.

Google describes (direct) / (none) as traffic without a clear referral source, and lists untagged links and redirects among the ways source information is lost (direct traffic). A paid buyer who comes back by typing the address shows there. That row is where a causal read begins.

A September report: the worked example

For example, with numbers made up for the sums and no store behind them: a homeware client's September dashboard, emailed as a PDF on 1 October and reopened on 15 October.

On the day of sending, the platforms claimed 934 - 861 = 73 more orders than the store received. Two weeks later, after Meta's late conversions arrived, the gap was 969 - 861 = 108, a claim ratio of 969 ÷ 861 = 1.13. The store's figure never moved.

A causal read sets none of these as its starting point. Per its how-it-works page, it reads the paths in the GA4 export, reassigns the Direct row to the channels that brought those customers, and lists each channel's caused share against a last-click version built from the same rows, with a 0 to 100 grade for how far the data holds and a next move to trial in one region. If it puts Paid Social well below Meta's 486, test that region before cutting the budget.

Before paying: two widgets and a date

Every part of this check runs inside DashThis at no extra cost:

1. Build a Calculated Widget that adds the purchase or conversion metric of each ad platform and divides by Shopify Total Orders. Set the format to Decimal and the fluctuation type to "Less is good" (calculated widget article).
2. Duplicate the Meta purchases widget and set Action Attribution Window on the copy to a click-only window. Whatever separates the two copies is credit Meta gives for views and for the days after a click.
3. Write the date in a comment box each time the report goes out, and refresh the last completed period before reading it again.

A ratio above 1.0 settles one question on its own: the platforms cannot all be right at once. It does not say which one to trust.

Limits on both sides

DashThis's default copies Meta's rule so that its widgets match Ads Manager, which closes the support ticket about mismatched numbers and leaves the larger mismatch, platforms against the store, outside the frame of every dashboard it ships.

The read has limits too. It asks for at least a year of GA4 history (how it works) and reads channels, so Bing Ads lands inside Paid Search with Google rather than as its own line. Any channel holding under 1% of credit by both counts gets no verdict, only the label too small to act on. Causality Engine's pricing page for agents adds that Unassigned traffic, with no tracked source, should be fixed in tagging first.

When the ratio is above 1.0, take the next step on the start page: nothing is charged for the first finding, which is computed locally. The full read from Causality Engine, which I founded, is a one-time €99, excluding VAT, with a refund inside 30 days (pricing, checked on 11 November 2026).

See also

• DashThis: plans by dashboards and sources
• How to use DashThis: one paid media dashboard across three platforms
• DashThis on the marketplace: DashThis's affiliate program terms
• Causality Engine: the causal read and what it costs
• How to use Causality Engine: export, read, then a one-region test
• Causality Engine on the marketplace: commission terms for referring the read
• How to find what Direct traffic is hiding: the (direct) / (none) row explained
• How to export GA4 data for attribution: the file the read takes

FAQ

Is there a DashThis integration for Causality Engine?

No. The two never exchange data. Causality Engine takes a CSV exported from GA4, and DashThis's GA4 widgets are a view of the same property, not that export (integrations page).

Why did last month's Meta purchases change after the report was sent?

Late conversions. Purchases inside the attribution window keep arriving after the period ends, and DashThis picks them up when the widget is refreshed; only Google Ads refreshes on its own (latent conversions article).

Should the client report use a click-only window for Meta?

My recommendation: show both. Keep the default widget so the figure matches Ads Manager, and add a copy filtered with Action Attribution Window so the client sees how much of the claim depends on views (attribution settings article).