Smart Bidding can only optimise toward what you measure. If your conversion tracking counts the wrong actions, counts them twice, or misses half of them, raising the budget just buys more of the wrong thing. Run the ten checks below before you scale any Google Ads account.

Why tracking comes before budget

The 10 point checklist

1. List every conversion action and its job

Open the conversions list and write down what each action measures. Mark each one as a real business outcome (lead, purchase, booked call) or a micro signal (scroll, video view, button click).

2. Keep only real outcomes as primary

Only primary actions feed bidding. Micro signals can stay as secondary for reporting. This one change fixes more accounts than any bid strategy tweak.

3. Check for duplicates

Look for the same action tracked twice, for example a Google Ads tag and an imported analytics goal both counting one form fill. Pick one source per action.

4. Set the right counting rule

5. Use enhanced conversions

Enhanced conversions send hashed first party data from your form or checkout so Google can match more conversions. It is free to switch on and usually recovers conversions lost to cookie limits.

6. Confirm consent mode is working

If you serve visitors in the UK, EU or other regions with consent rules, check that consent mode is set up and that tags respect the visitor's choice. A broken consent setup can silently drop a large share of conversions.

7. Test the thank you path end to end

Submit a real test lead or order. Confirm the tag fires once, on the right page, and that the conversion appears in the account within the expected delay. Use Tag Assistant or your tag manager's preview mode, both free.

8. Import offline outcomes

If sales happen after the form fill, import qualified leads or closed deals from your CRM. This lets bidding learn which clicks turn into revenue, not just which clicks fill forms.

9. Assign values

Even rough values help. If a qualified lead is worth more than a newsletter sign up, say so in the conversion value. Value based bidding needs this.

10. Review the attribution model and window

Check that the conversion window matches your sales cycle. A 30 day window on a product that takes 60 days to close will undercount results.

Quick audit table

Common mistakes

1. Counting "Contact page view" as a lead. It is a visit, not a lead.
2. Changing tracking and budget in the same week. You will not know which change moved the numbers.
3. Ignoring the CRM. If your ad account and your CRM disagree, trust neither until you find out why.
4. Switching to value bidding with no values. Bidding needs a signal to work with.

Final thought

Clean tracking is the cheapest performance gain in Google Ads. Fix what you measure first, then scale.

I run Google Ads, Meta Ads, SEO and AI search (AEO and GEO) work, and build AI agents for marketing teams. More at vickylalwani.net.

Ship honest JSON-LD that matches visible page text, especially Organization, Person, Service and FAQ where the FAQ is real. Add an /llms.txt only as a courtesy map for agents that choose to read it. Google Search says it ignores llms.txt and does not need special AI files for AI Overviews or AI Mode. Useful crawlable pages still matter most. (Google AI features, llmstxt.org)

Two different jobs

People mix these up:

Google's AI features documentation states there are no additional technical requirements beyond normal indexing and snippet eligibility, and you do not need new machine readable AI files. (AI features and your website)

Schema that helps humans and machines

1. Organization on the home or about page

Google's Organization structured data guide recommends placing administrative details on the home page or a single about page, not on every URL. Include the properties that apply: name, url, logo, sameAs, contactPoint and address when you have one. (Organization schema)

For a consultant brand, sameAs should point to real profiles you control (LinkedIn, directories). Do not invent profiles.

2. Person for the named expert

If pages say a named person does the work, mark that person up with name, jobTitle, url and sameAs that match the visible bio. Keep the bio identical across site and profiles so entities do not conflict.

3. Service on service pages

Describe each service with name, description, provider and areaServed when you truly serve those areas. If you claim Australia, the UK and the US, the visible copy should say that too.

4. FAQPage only for real FAQs

FAQ markup must match questions and answers shown on the page. Fake FAQ blocks built for rich results are a trust problem and a policy risk. Google's AI guidance also says structured data should match visible text. (AI features docs)

5. Article on guides

Blog posts can use Article with headline, datePublished, dateModified and author. Update dateModified only when you truly update the piece.

Validation checklist

What llms.txt actually is

The llms.txt proposal is a markdown file at /llms.txt (or under a path) with:

• an H1 site name (required)
• a short summary blockquote
• optional notes
• H2 sections with curated links to more detail, ideally LLM friendly markdown versions of pages

Agents may read it, then follow links. It is meant to stay small. (llmstxt.org)

It does not replace robots.txt. It does not force ChatGPT or Perplexity to cite you.

Should you bother with llms.txt?

Yes, if you already have clear docs or service pages and want coding agents or research agents to find the right URLs quickly.

No rush, if your crawl, titles, headings and schema are still messy. Fix those first. Google's generative AI guide puts unique, useful content and normal SEO fundamentals above special AI packaging. (AI optimization guide)

Google's documentation updates note that maintaining llms.txt will not help or harm Google Search visibility because Search ignores those files. (Search updates)

A minimal llms.txt shape

# Your Brand Name

> One or two sentences on what you do and who you serve.

Optional paragraph on how to read the links below.

## Services
- [GEO](https://www.example.com/services/geo): AI search visibility work
- [Google Ads](https://www.example.com/services/ppc): paid search management

## Key guides
- [AI visibility audit checklist](https://www.example.com/insights/ai-visibility-audit): how we baseline prompts

Link only live URLs. Keep notes factual. No hype.

Implementation order for a small site

1. Fix robots and indexation on money pages.
2. Add Organization and Person JSON-LD that match the about page.
3. Add Service JSON-LD on each service URL.
4. Add real FAQs only where users already ask those questions.
5. Validate samples.
6. Add /llms.txt as a curated map.
7. Optionally publish .md mirrors for a few cornerstone pages if your stack makes that easy.

Common mistakes

• Schema that claims a street office you do not have
• FAQ schema for questions not on the page
• llms.txt stuffed with every blog URL like a second sitemap
• Expecting llms.txt to move Google AI Overviews
• Changing Organization name spelling across pages

Example Organization JSON-LD (illustrative)

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Example Consult Co",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/in/example"
  ],
  "areaServed": ["AU", "GB", "US"]
}

Change every field to match visible truth. Google's Organization guide prefers specific subtypes when they fit. (Organization schema)

How this ties to GEO measurement

Schema will not force a citation. It reduces entity confusion. Your GEO programme still needs prompt panels, third party mentions and pages worth quoting. Think of schema as labelling the jars, not cooking the meal.

robots.txt and AI crawlers, kept simple

Before schema theatre, confirm money pages are allowed in robots.txt and not blocked by accidental noindex. Google lists crawl allowance as part of normal SEO that still applies for AI features. (AI features docs)

Some teams also review logs for GPTBot and other AI user agents. That is a policy choice about training and retrieval access. It is separate from ranking. Do not confuse "blocked training crawl" with "invisible in AI answers that browse the live web."

Copy rules that make markup worth doing

Write the page so a stranger understands the offer without schema. Then mark it up. If the HTML is vague, JSON-LD cannot save it. Google's generative AI guide pushes unique, people first content over commodity tip lists. (AI optimization guide)

Practical page checklist:

• H1 states the service in normal words
• First screen answers who it is for
• One comparison table or steps list
• Author or company bio with real credentials
• Dates on research claims

Maintenance cadence

Soft next step

Schema and crawl hygiene sit inside a wider GEO programme. I keep that outline on vickylalwani.net/services/geo-generative-engine-optimization. Ship the checklist above before you chase exotic AI files.

Sources

1. Google Search Central, AI Features and Your Website: https://developers.google.com/search/docs/appearance/ai-features
2. Google Search Central, Optimizing for Generative AI Features: https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
3. Google Search Central, Organization structured data: https://developers.google.com/search/docs/appearance/structured-data/organization
4. Google Search Central, documentation updates (llms.txt note): https://developers.google.com/search/updates
5. llms.txt specification: https://llmstxt.org/

A lead capture chatbot should talk, qualify and write to your CRM only inside hard limits you set in code. The model proposes a tool call. Your app decides whether that call is allowed, asks a human when the action is risky, then returns the result. OpenAI and Anthropic both document this pattern: the model never executes your CRM write by itself. (OpenAI function calling, Anthropic tool use)

The problem this solves

Most "AI chatbots" for lead capture do one of two unsafe things:

1. They only chat and never write a lead anywhere useful.
2. They get a wide API key and can create, update or delete CRM records with almost no checks.

You want a third path: the bot can create a lead when the visitor is ready, and it cannot do anything else.

What "tool permissions" means

A tool is a function your application exposes to the model, with a name, a description and a JSON schema for inputs. The model can request that function. Your server runs it, or refuses it.

Permissions are the rules around that run:

• which tools exist at all
• which fields each tool may set
• whether a human must approve first
• what happens on failure
• how you log every attempt

OpenAI describes the loop as: send tools, receive a tool call, execute on your side, send the tool output back, get the next model response. (Function calling guide) Anthropic uses the same idea with tool_use and tool_result blocks. (Tool use overview)

Build it in eight steps

1. Write the job in one sentence

Example: "Qualify a website visitor for a marketing consult and create a CRM lead only when email, market and need are present."

If the sentence includes billing, refunds, password resets or inbox access, split those into other products. Lead capture is enough for version one.

2. List the tools before you write prompts

Start with four tools or fewer:

Fewer tools mean fewer ways to fail.

3. Define each tool schema tightly

For create_lead, allow only fields you need:

• full_name (string)
• work_email (string, must look like an email)
• company (string, optional)
• market (enum: AU, UK, US, other)
• need (enum: GEO, SEO, Google Ads, Meta Ads, AI chatbot, other)
• notes (string, max 500 chars)

Reject extra keys. Reject empty email. Reject need values outside the enum. The model can still ask the visitor for missing fields in chat.

Anthropic's tool definition fields are name, description and input_schema. Write the description like an ops manual: when to call it, when not to, and what "success" means. (Define tools)

4. Keep side effects behind an approval gate

Creating a CRM lead is a side effect. OpenAI's agent guidance treats human review as the path for sensitive tool calls: the run pauses, you approve or reject, then you resume from saved state. (Guardrails and human review)

Practical version for a marketing site bot:

• First create_lead attempt in a session shows the visitor a confirm card: "Save this enquiry to our team?"
• Only after confirm does your server call the CRM.
• Log the approval with timestamp and hashed email.

Do not let the model invent approval. Approval is a UI click or a staff action in your app.

5. Run tools in your process, not in the prompt

Never paste CRM API keys into the system prompt. Never ask the model to "pretend" it wrote the lead. Your code:

1. validates the tool name against an allowlist
2. validates arguments against the schema
3. checks session rate limits (for example one create_lead per email per day)
4. calls the CRM with a scoped token that can only create leads
5. returns a short structured result to the model (ok, lead_id, or error_code)

If validation fails, return a clear error the model can explain to the user. Do not retry blindly.

6. Add input and output guardrails

Before the main model runs, block jailbreak attempts that ask for system prompts, other users' data or bulk exports. After the model answers, strip secrets if any tool result accidentally included them.

OpenAI separates input guardrails, output guardrails and tool guardrails. Put checks next to the tool that causes the side effect, not only at the outer agent. (Guardrails docs)

7. Test with hostile scripts, not happy paths

Write a test sheet:

Ship only when the hostile rows pass.

8. Log enough to debug, not enough to leak

Store:

• session id
• tool name
• validation pass or fail
• approval state
• CRM status code
• truncated error text

Do not store full card numbers (you should not collect them here anyway). Hash emails in analytics if your privacy policy says you will.

Suggested conversation flow

1. Greet and ask what they need in one question.
2. Ask market and company size band if needed for routing.
3. Call score_lead locally.
4. If score is low, offer a guide link and stop.
5. If score is high, summarise what you heard and ask to save the enquiry.
6. On confirm, call create_lead.
7. Confirm receipt and offer a calendar link or email follow up from a human.

The bot is a front door. A person still owns the relationship.

Minimal architecture

Browser widget
  -> your API (auth, rate limit)
    -> model with tool definitions
    -> tool router (allowlist + schema)
      -> CRM create endpoint (scoped token)
    -> approval store
  -> response to widget

Swap CRM for a Google Sheet in week one if you must. Keep the same permission shell so you do not rebuild later.

Edge cases that break lead bots

Partial emails. Visitors type "name at company". Do not call create_lead until the address parses. Ask once more in plain words.

Agents talking to agents. Some visitors paste another model's output. Your bot should still follow the same schema. Do not widen tools because the message looks technical.

Staff testing in production. Use a test_mode flag that writes to a sandbox CRM or a labelled test lead. Keep production tools blocked for known staff emails if you can.

Multi market routing. If market is AU, UK or US, route the notification to the right inbox or owner. Do not invent a market from IP alone without telling the visitor what you assumed.

Tool storms. Cap tool calls per turn. If the model requests three CRM writes in one reply, reject all but the first valid create after approval.

Privacy copy you should show

Near the confirm button, state:

• what you store
• who on your team sees it
• how they can ask for deletion

That text belongs in your UI, not only in a buried policy page. The bot can summarise it, but the confirm card should show it too.

Soft next step

I publish a longer view of chatbot and agent builds for marketing teams on vickylalwani.net/services/ai-chatbots. Use this permissions checklist first so any builder you hire inherits the same limits.

Sources

1. OpenAI, Function calling: https://developers.openai.com/API/docs/guides/function-calling
2. OpenAI, Guardrails and human review: https://developers.openai.com/api/docs/guides/agents/guardrails-approvals
3. Anthropic, Tool use overview: https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
4. Anthropic, Define tools: https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools