Google Ads conversion tracking needs 3 connected checks: a clearly defined business event, consent-aware tag behaviour and reproducible test evidence. A button click, a successful enquiry and a completed purchase describe different outcomes; treating them as the same signal can make campaign reports misleading.
For a Zambian business, the starting point is your customer journey rather than a default event list. Identify where a genuine outcome becomes known, which system knows it and whether that evidence can reach the measurement setup. The technical guidance here describes Google’s documented products. It does not determine your privacy obligations or promise that every visitor can be measured.
Which events should your conversion setup actually count?
Write a plain-language definition for each candidate conversion. “Enquiry accepted by the website” is clearer than “contact interaction”. State what has to happen before it counts and what must not count. A visitor opening a form should not satisfy a rule intended to measure successful submission. A failed checkout should not satisfy a completed-order rule.
Google’s web-conversion setup guidance distinguishes URL-based measurement for simple page loads from code-based measurement for interactions and transaction-specific details. Use the distinction to choose implementation, not to redefine the outcome. A confirmation-page URL may be useful only if reaching that page reliably corresponds to the event you intend to measure.
Consider revisits and repeated submissions. If a confirmation URL can be opened directly, a page-view event alone may lack evidence of a new enquiry. If a purchase event includes transaction information, test what happens when the confirmation is refreshed. Google documents code-based support for transaction IDs and dynamic values, but the correct identifier still has to come from your actual transaction system.
Check whether the same action already arrives through another route. The setup guidance warns that content-management plugins can double-tag a website and duplicate conversion reporting. Inventory the website plugin, Google Tag Manager container, directly embedded code and imported Analytics events before adding anything. An event name alone does not tell you which installation generated it.
Analytics imports have their own prerequisites. Google specifies Ads Admin access, Edit access in the linked Analytics property and events marked as key events. Verify the property as well as the event: a similarly named property belonging to a staging site or another business is not an adequate substitute. Record the account and property references without exposing credentials.
Also distinguish actions used for bidding from actions retained for observation. Google’s primary/secondary guidance makes the campaign goal relevant: a primary action is used for bidding when its goal is selected for bidding. Secondary actions normally support observation, but actions in a custom goal are used for bidding regardless of the primary/secondary label. A useful diagnostic event does not automatically belong in the same category as a confirmed business outcome. Write the intended use beside the event definition so a future account change does not erase that distinction.
Set the conversion-counting option deliberately. Every counts conversions for the tracked action after an ad interaction; One counts one conversion per ad click for that action. Google presents Every as useful for sales and One for lead generation where repeat forms should not multiply the lead signal. This setting does not replace fixing duplicate tags or defining a genuine outcome.
The implementation path is then concrete: create the conversion action, choose the Google tag or linked Analytics source, select URL setup for a justified page-load outcome or code for interaction/transaction details, configure counting and campaign-goal use, then test the defined event and inspect its status. For Analytics imports, first satisfy the linked-property, access and key-event prerequisites described above.
Use this original evidence matrix before changing campaign settings. The examples describe proposed tests, not results from a Spout customer account.
| Journey state | Intended meaning | Evidence to capture | Question to resolve |
|---|---|---|---|
| Form opened | Visitor begins an interaction | Event name and trigger | Is this observation only? |
| Form rejected | Website did not accept the enquiry | Validation response and absent success event | Does failure accidentally count? |
| Form accepted | Website accepted the submission | Success response and event payload | Is acceptance known before the tag fires? |
| Confirmation revisited | Existing outcome viewed again | Repeated-navigation trace | Does the same outcome count again? |
| Consent declined | Visitor’s choice is applied | Consent state and tag behaviour | Does implementation match the chosen mode? |
| Consent changed | A new choice replaces the earlier state | Updated state and subsequent requests | Are tags responding to the update? |
Keep the definition of success next to the evidence. A screenshot of a tag firing is weak evidence if the underlying business action was never accepted.
How do you prove consent handling and event behaviour work together?
Consent is part of the measurement design. Google’s consent-mode overview explains that developers must obtain the user’s choice, communicate its state and make tags behave accordingly. Consent mode adjusts supported tag behaviour; it does not itself replace the process of asking the visitor or establish that a particular consent notice is appropriate for your business.
Select the implementation deliberately. In basic consent mode, Google tags are blocked until interaction with the consent banner and remain blocked where consent is not granted. In advanced consent mode, tags load with configured defaults and may send measurements without cookies while consent is denied. These modes should not be described as equivalent forms of “no tracking”. Inspect the actual network behaviour against the documented mode.
Write down which consent types your configuration uses. The overview distinguishes advertising storage, analytics storage, advertising user data and advertising personalisation, among others. A single visual banner control can conceal several technical settings. Your evidence should show the states that matter to the tags, rather than merely proving the banner appeared on screen.
Test a fresh visit before interacting, then a declined choice, then a granted choice. Include a return visit and a changed choice where supported. These are distinct scenarios because the event trigger may work while consent updates fail, or consent may update while the success event fires at the wrong stage. Save what happened alongside what you expected, including any unexplained requests.
Use test records that cannot be confused with genuine leads. Give each scenario a readable reference and retain the event name, trigger, consent state, destination account and observed outcome. Redact personal information from screenshots and traces. A measurement handover should help the next operator reproduce behaviour without distributing customer data or authentication material.
Google’s setup guide directs advertisers to check the conversion action’s status in the account. Include that check, but do not treat a status label as proof of the whole journey. It cannot, by itself, tell you whether your definition of an accepted enquiry is correct or whether two separate implementations are counting it.
When results disagree, reconcile them by event meaning. A website acceptance log and an advertising report answer different questions and may not contain the same set of journeys. Investigate the trigger, consent behaviour and duplicate paths before labelling the campaign ineffective. Avoid inventing a target discrepancy or claiming complete coverage that the implementation cannot provide.
For related campaign context, see Spout’s Google Ads page. Get started with your intended outcome and a redacted version of this matrix. Keep account access separate from the initial brief, and retain unresolved privacy and implementation questions in the scope rather than assuming a tag installation settles them.
By Spout Team. AI-assisted drafting by Codex, grounded in the linked primary documentation.