Account audits

Find the login, payment and booking referrals that steal conversion credit in GA4

Proves with source, event and landing page breakdowns whether GA4 credits conversions to an external login, payment or booking domain when visitors return from it. Lists the domains to add to unwanted referrals and the mess in paid source names.

When to use it

When your site uses Google sign-in, an external payment page or a booking system, and you notice that a large share of conversions in GA4 seems to come from the Referral channel.

What you get

An evidence-based table of referrals that steal conversions, the share of key events whose source is therefore unclear, one standard for paid source names and the exact list of domains to enter in GA4. No setting changes.

Does it change anything in my account?

No. The assistant only reads your data and reports back.

Works with

GA4

Fill in before sending

[GA4 property]

Some conversions in my GA4 property [GA4 property] may be showing the wrong source. When a visitor leaves my site for an external domain such as Google sign-in, a payment provider or a booking system and then comes back, GA4 can start a new session and credit the conversion to that domain. Prove whether this is happening. The external services I use: [your payment, login, appointment or booking providers, or write "not sure"]. This is a read-only review. 1. Confirm the property. List the property with ga4_list_properties, the web streams and measurement IDs with ga4_list_data_streams and the key events with ga4_list_conversions. 2. Pull the sources. With ga4_report, pull the last 28 days with dimension=channel and dimension2=source_medium and separate the rows in the Referral channel. 3. Tie key events to sources. With ga4_report, use dimension=event and dimension2=source_medium to see which source each key event comes from. Without dimension=event, the conversions column is the sum of every key event in the property, so do not skip this step. 4. Look at landing pages. With ga4_report, use dimension=landing_page and dimension2=source_medium. Find referral sessions that land on pages such as a login return (for example /auth/.../callback), a post-payment thank-you page or a booking confirmation page. Rules for a suspicious referral: 1. Referral rows whose source is a login service (accounts.google.com, login.microsoftonline.com, appleid.apple.com and similar), a payment provider or a booking system. 2. My own domain or subdomains showing up as referrals. 3. Referral rows whose key events per session are more than twice the site average. 4. Referral sessions whose landing page is a return, thank-you or confirmation page. Format the output like this: 1. Suspicious referrals table: source / medium, channel, sessions, key events, most common landing page, why it is suspicious. 2. The total key events in those rows and their share of all key events. GA4 data alone does not show the true source of these conversions; say so plainly and do not estimate a redistribution. 3. Rows in paid channels where the same platform appears under several names (for example fb / paid, ig / paid, meta / paid, or a source that lands in Paid Other), with one proposed utm_source and utm_medium standard for them. 4. To do: the domains to add to the unwanted referrals list in GA4 and, where needed, the domains to configure for cross-domain measurement. No tool changes these settings; I will enter them under Admin > Data streams > web stream > Configure tag settings in GA4, so write the domains exactly. Note that the change does not fix past data, it only affects sessions from then on.

1. Confirm the property. List the property with ga4_list_properties, the web streams and measurement IDs with ga4_list_data_streams and the key events with ga4_list_conversions.
2. Pull the sources. With ga4_report, pull the last 28 days with dimension=channel and dimension2=source_medium and separate the rows in the Referral channel.
3. Tie key events to sources. With ga4_report, use dimension=event and dimension2=source_medium to see which source each key event comes from. Without dimension=event, the conversions column is the sum of every key event in the property, so do not skip this step.
4. Look at landing pages. With ga4_report, use dimension=landing_page and dimension2=source_medium. Find referral sessions that land on pages such as a login return (for example /auth/.../callback), a post-payment thank-you page or a booking confirmation page.

Rules for a suspicious referral:
1. Referral rows whose source is a login service (accounts.google.com, login.microsoftonline.com, appleid.apple.com and similar), a payment provider or a booking system.
2. My own domain or subdomains showing up as referrals.
3. Referral rows whose key events per session are more than twice the site average.
4. Referral sessions whose landing page is a return, thank-you or confirmation page.

Format the output like this:
1. Suspicious referrals table: source / medium, channel, sessions, key events, most common landing page, why it is suspicious.
2. The total key events in those rows and their share of all key events. GA4 data alone does not show the true source of these conversions; say so plainly and do not estimate a redistribution.
3. Rows in paid channels where the same platform appears under several names (for example fb / paid, ig / paid, meta / paid, or a source that lands in Paid Other), with one proposed utm_source and utm_medium standard for them.
4. To do: the domains to add to the unwanted referrals list in GA4 and, where needed, the domains to configure for cross-domain measurement. No tool changes these settings; I will enter them under Admin > Data streams > web stream > Configure tag settings in GA4, so write the domains exactly. Note that the change does not fix past data, it only affects sessions from then on.

Open in Claude Open in ChatGPT Discuss in the forum

Example result

An example of the output this prompt produces. Its structure comes from the tools' real output; numbers and names are fictional.

Example output (based on a fictional account, not real customer data)

Property: sampleclinic.com (G-XXXXXXX), key events: generate_lead, purchase.

Source / medium	Channel	Sessions	Key events	Most common landing page	Why suspicious
accounts.google.com / referral	Referral	188	64	/auth/google/callback	Login service, return page
pay.samplepos.com / referral	Referral	52	47	/order/complete	Payment provider, thank-you page
booking.sampleclinic.com / referral	Referral	31	22	/booking/confirmed	My own subdomain

These three rows carry 133 key events, 38% of all key events in the property. The true source of these conversions (ads, organic, direct) cannot be recovered from GA4 data after the fact.

Paid source mess: Meta traffic is split three ways as fb / paid, ig / paid and meta / paid; the an / paid row lands in Paid Other. Proposal: use utm_source=meta, utm_medium=paid_social and move placement into utm_content.

To enter in GA4
1. Unwanted referrals: accounts.google.com, pay.samplepos.com
2. Cross-domain measurement: sampleclinic.com, booking.sampleclinic.com

The change does not fix past data, it only affects sessions from then on.

More prompts

Account auditsRead-only

Full Google Ads account audit with the three fixes to make first

Reviews the whole account in one pass, from measurement and bidding to structure and landing pages. Ranks the findings by impact and names the first three fixes without changing anything.

When to use itWhen you inherit or doubt a Google Ads account and want to know what is actually wrong and where to start fixing it.

Audit my Google Ads account [account name] end to end. If the account is younger than 90 days use every day available, otherwise use the last 90 days. This is a read-only review, do not change anything.

Start with account_snapshot to get each campaign's status, budget, bidding strategy, age and results since it started. Separate the campaigns that bring results from the ones that spend without converting. Then work through these areas in order:

1. Measurement. List the primary conversion actions with list_conversion_actions. Flag any primary action that recorded nothing in the last 30 days. Look for setups that can count the same person twice, for example a phone click and a WhatsApp click on the site set up as two separate primary actions, or the Google Ads tag and an imported GA4 event both primary for the same form. Check how many clicks went to the call button in the ads and whether those calls were actually recorded, using google_ads_query on call_view.
2. Bidding and budget. Use impression_share_analysis to show, per campaign, the impression share lost to budget and to rank. Use keyword_quality_report to find keywords below the first page bid or rarely shown because of low quality. For campaigns on Smart Bidding, say whether the last 30 days hold enough conversions for the target they use.
3. Structure. Check whether brand searches share a campaign with generic searches, whether every ad group sends people to the page for its own service, and whether the same keyword sits in more than one ad group.
4. Search terms. Use search_terms_report to separate terms that spend without converting, competitor brands and informational searches. Never count a term with at least one conversion as waste.
5. Ads and assets. Review ad strength, disapproved assets and whether sitelinks point to the right page. Flag separately any copy or asset that describes a service the business does not offer: [services not offered, or write "none"].
6. Landing pages. Pull clicks, cost and conversion rate per page from landing_page_view with google_ads_query. On the pages that take the most spend, check that a phone and a WhatsApp button exist and check mobile speed with core_web_vitals.
7. Location, schedule and device. Show whether the location option is set to "Presence", how much spend goes outside the target area, and the spend and conversions outside [business hours].

Format the output like this: first a five-sentence summary of where the account stands. Then a findings table ranked by importance: problem, evidence, estimated impact, recommendation. At the end, the three fixes to make first and why each one comes first. Where the data is not enough for a conclusion, do not guess, say what is missing.

Account auditsRead-only

Full Meta Ads account audit with the three fixes to make first

Reviews measurement, delivery issues, the learning phase, targeting, placements and creative fatigue in one pass. Ranks the findings and names the first three fixes without changing anything.

When to use itWhen your Meta ads results have slipped or stalled and you need to know what is wrong in the account before touching anything.

Audit my Meta ad account [ad account] end to end. Use the last 30 days as the main period and the 30 days before that as the comparison. This is a read-only review, do not change anything.

Start with account_snapshot for platform meta to get each campaign's status, budget, objective, age and results since it started. Meta has no single conversion count, so use the result each campaign actually optimizes for (leads, messaging conversations started, purchases). Then work through these areas in order:

1. Measurement. Check the pixel's last event time with list_meta_pixels. Confirm that the event each campaign optimizes for is actually recording. Flag setups that can count the same result twice, for example leads collected by both the pixel and an instant form.
2. Delivery. List ad sets that are rejected, stuck in review, have no active ad left, or spend less than half of their budget. Give Meta's stated reason for each.
3. Learning phase. Find ad sets split so thin that they cannot reach 50 results a week. Use meta_change_history to show edits in the last 14 days that reset learning.
4. Targeting and audiences. Flag ad sets that target the same audience and ad sets whose frequency is above [maximum frequency].
5. Placements and devices. With get_report, compare cost per result by publisher_platform and by device against the account average. Do not decide on segments with fewer than 20 results.
6. Creatives. Treat an ad as fatigued when frequency rises while click-through rate falls and cost per result climbs. Briefly describe the angle the winning ads share.
7. Destination. Check that the page or WhatsApp link the ads send people to works and matches the objective.

Account auditsChanges after your approval

Merge phone and WhatsApp enquiries into one reliable conversion

Stops one person being counted twice when they both call and message. Ties the two buttons on the site to a single conversion and checks whether the call button in the ads is measured at all.

When to use itWhen people call and message you from the same site and you suspect one visitor is being counted as two conversions, making your cost per conversion look better than it is.

In my Google Ads account [account name], prospects reach us through the phone and WhatsApp buttons on the site. If one person pressing both buttons counts as two conversions, my cost per conversion looks cheaper than it is and the bidding algorithm learns the wrong thing. Fix this.

1. Map the current setup. List the primary actions, their categories and counting types with list_conversion_actions. In my Tag Manager container [GTM container ID], use list_gtm_tags to show which tag fires which conversion label. Estimate with numbers how often one ad click may have produced more than one contact conversion in the last 30 days.
2. The call button in the ads. With google_ads_query, check how many clicks and how much spend went to the call button in the ads, and use call_view to check whether those calls were recorded. If there are clicks but no records, say so clearly and offer two options: remove the call asset, or accept those clicks as unmeasured traffic.
3. Show the plan. Propose a single conversion action named "Contact click (Phone + WhatsApp)" with counting set to one. Tie it to one tag that fires on both the phone and the WhatsApp trigger. Make the two old actions secondary. Say whether campaigns on Smart Bidding need their target reviewed, because the conversion count will drop.
4. Apply after my approval. Create the conversion action, set counting to one, update the tag in Tag Manager and show me the list of changes before publishing. After publishing, write down which version can be restored.

Finish with a short test plan: how to see in preview mode that only the new tag fires when both buttons are pressed, and how many days it takes for the fix to show in real data.

Account auditsRead-only

Run a full SEO, AEO and GEO audit and get an evidence-backed scorecard

Scores access, technical health, structured data, quotability of content, trust signals and measured AI visibility in six areas of five concrete checks each. Shows the evidence for every point and orders the fixes by impact and effort, without changing anything.

When to use itYou want one evidence-backed report showing where your site stands in Google and in AI search, and a clear task list to hand to an agency or developer.

Audit my site [site URL] end to end for classic search, answer engines (AEO) and AI search (GEO). My Search Console property: [Search Console property]. Main competitor: [competitor domain, or "none"]. Market: [country], language: [language code]. The 3 searches that bring me the most business: [3 commercial queries]. My most important page templates: [homepage, one service page, one blog post URL]. This is read-only.

Credit rule: before starting, check earlier runs with seo_history and call the reusable ones again with the same arguments. Show me once the list of new calls that will spend credits and get my approval.

Data collection:
1. Run the bundled analysis with seo_full_analysis, passing domain, competitor, location and language. Its AI visibility section measures the single keyword the site ranks for most, which may have nothing to do with my business; do not use that section for scoring, and instead measure my 3 commercial queries with seo_ai_overview and target=[domain]. If references is empty, count the domains of the links inside ai_answer.
2. Run seo_site_crawl with max_pages close to the site's page count (at most [page limit]). It returns a task_id; call it again with the same task_id after 60 to 90 seconds and wait until the summary arrives. Pull the full URL list of an issue with the issue parameter when needed. If the crawl limit does not cover the whole site, say the results are a sample.
3. Read robots.txt, sitemap.xml and llms.txt with site_read_url. Read my template pages with text=true (if truncated is true, again with max_bytes=1000000) and with outline=true. For JSON-LD, read the same pages with max_bytes=1000000 and extract the blocks.
4. Measure the homepage and the service page with seo_audit and strategy='mobile'. For Core Web Vitals use real-user (field) data where it exists, otherwise the lab value, and say which one you used.
5. Use get_report with platform='search_console' and breakdown 'query by impressions' and 'page by impressions' for the last 90 days. Inspect the 10 pages with the most impressions with gsc_inspect_urls. Get the sitemap status with gsc_sitemaps.
6. Remember that different tools can see different versions of the same page: if seo_technical_audit or seo_site_crawl measures a title in a different language from what site_read_url shows, record it as a finding, because the site may be redirecting visitors by country.

Scorecard: six areas, five checks each, each check pass (1) or fail (0). If a check has no data, write "not measured" and drop it from the denominator; never score by guessing.
1. Access and crawlability: robots.txt is open to search-role AI crawlers; key pages return 200 with at most one redirect; no noindex on key pages; the sitemap has no errors and contains the key pages; the main content is visible without JavaScript.
2. Technical health and speed: mobile LCP under 2.5 seconds; CLS under 0.1; INP under 200 ms; no broken pages or broken internal links in the crawl; no duplicate titles or descriptions.
3. Structured data and entity: an Organization or LocalBusiness node exists; nodes are linked by @id; the schema fits the page type (Service, Article, Product); schema facts match the visible text; sameAs URLs work.
4. Quotability of content: the first paragraph of key pages answers the question directly; headings name the topic or question clearly; comparable facts are in a table; a page-specific FAQ exists; there are concrete numbers and dates.
5. Trust signals: the about page is concrete (who, where, since when); contact details are on the site and consistent; posts show an author or publisher; publish and update dates are visible; legal pages are reachable from the footer through static links.
6. Measured AI visibility: cited in Google's AI answer for at least one of the 3 commercial queries; cited for the brand query; llms.txt exists and is accurate; Search Console shows clicks from non-brand queries; if the main competitor is cited on these queries, there is at least one where I am cited too.

Format the output like this. First a five-sentence executive summary. Then the score table: area, score (e.g. 3/5), failed checks. Then the evidence table: area, check, result, evidence (tool name and returned value), affected URLs. Then the fix list: for each item the impact (high, medium, low), the effort (hours, days, weeks) and who does it; high impact and low effort first. At the end, the first three fixes and why they come first. Do not pass judgement on anything that was not measured.