The short answer
A payment provider appearing in a report does not by itself establish that advertising failed. Trace the route from the store to payment and back. Consider only referrals confirmed to be part of the transaction workflow; do not exclude all referral sources.
| Check | Record | Not proof of success |
|---|---|---|
| Report | Dimension, period and source | One screenshot |
| Journey | Store, payment and return | Page opening |
| Condition | Verified domain and scope | Saved configuration |
| Outcome | Test and store evidence | Referral row disappearing |
Record the reporting question first
Write down the report, date range and source dimension showing the issue. Session acquisition and other attribution views should not be treated as identical totals. In a paid marketing review, distinguish a changed channel label from a completed store order. One screenshot does not establish that every sale was misattributed. Keep the observed scope and the transaction journey available for the technical reviewer.
Distinguish a payment return from a genuine referral
Google’s official guidance includes third-party payment processors returning visitors to a store as a use case for unwanted referrals. Matching conditions tell Analytics not to use the referrer as a traffic source. This does not mean removing the entire visitor or payment from measurement. A link from a publisher or genuine partner recommendation serves a different purpose. Do not exclude those sources merely to make a report look tidier.
Verify the actual domain and condition scope
Imagine a store sending a visitor to another domain for payment before returning to an order-result page. Record the domain actually observed in that journey. Do not guess a similar domain name. The responsible specialist should explain which addresses a proposed condition matches. This fictional workflow is not a ready-made configuration for a specific bank or provider; read the existing account conditions before making changes.
Define an authorised test before changing anything
Record the current setup, proposed reason, owner and reversal note. The authorised team can inspect an appropriate, clearly labelled test purchase journey. Check the starting source, payment transition and return measurement separately. Saving a setting is not evidence that the journey works. Separate tests from actual sales and do not create a paid transaction solely for inspection without the business’s permission.
Do not assume historical reports will immediately change
Google explains that earlier referrals and returning-user attribution history can cause excluded domains to remain visible in reports. Record when the condition changed and define the new behaviour and observation period being tested. Seeing an old row is not a reason to repeatedly broaden exclusions. Findings remain limited to accessible evidence; complete tracking of every device and conversion is not guaranteed.
Keep the advertising decision wider than one setting
Reviewing unwanted referrals does not automatically repair a missing purchase event or an incorrect order amount. Assess cross-domain measurement needs separately. In an analytics review, the store outcome, measured event and campaign attribution remain distinct evidence layers. Find the stage where the observed problem occurs and test that change. Do not raise a channel budget simply because one referral row disappears.
A starting checklist
- State the reporting scope.
- Verify the actual payment domain.
- Preserve genuine referral sources.
- Assign a test owner and time.
- Separate history from new tests.
- Verify the store outcome independently.
The Adsimurg approach
Adsimurg assesses advertising reports alongside measurement and operational outcomes. A free Advertising and SEO audit can review source uncertainty in a payment-return journey. The initial review is not an account-setting change or a performance guarantee.
Explore the relevant service scopes to put this plan into practice: Paid marketing, Growth strategy & analytics.