Conversion UploaderSign in
New North Digital · Legal

How matching works

Last updated: 21 August 2026

This page explains, without jargon, how we work out that an invoice in your accounting system started with someone clicking one of your ads. It is written to be shared: if a client, a DPO or an auditor asks “how do you know that sale came from Google?”, this is the answer.

The problem

Google Ads can see a click. It cannot see what happens weeks later in your ERP or accounting system. For a webshop the gap is small, because the order and the click happen in the same browser session. For anything invoiced later — a quote, a phone order, a deal closed by email — the trail breaks, and the advertising that produced that revenue looks like it produced nothing.

The Uploader closes that gap by sending the finished, invoiced deal back to Google, together with something that identifies which click it belongs to.

The two ways we tie a deal to a click

1. The click id. When someone arrives from an ad, Google puts an identifier in the landing URL (a gclid). A tag on your site stores it in a first-party cookie on your own domain. When that visitor later places an order or requests a quote, the tag sends us the click id together with a reference we can find again on the invoice: the webshop order number, or a hashed version of the email address. When the invoice arrives, we look that reference up and upload the conversion with the original click id attached.

This is the accurate route. Google is not guessing: it is being told exactly which click this revenue belongs to.

2. The email address. Where no click id was captured, we send a hashedversion of the customer’s email address instead (SHA-256, a one-way fingerprint — the address itself is not sent). Google compares that fingerprint against accounts that clicked an ad. This is Google’s standard enhanced conversions mechanism. It works, but it degrades: on Safari the link between an email address and a click expires after about 24 hours, and it fails entirely when the invoice goes to a different address than the person who placed the order (a purchasing manager orders, the accounts department is invoiced).

Route 1 exists because route 2 alone leaves real revenue unattributed. Where we have both, the click id wins, because it names one specific click rather than a person.

What is stored, and for how long

  • Order number and click id— no personal data at all. Kept 120 days, which covers Google’s 90-day click window plus the lag before an invoice appears.
  • Hashed email and click id— the address is never stored in readable form, only its SHA-256 fingerprint. Same 120-day retention. It is still personal data, so it is covered by erasure requests: see the Data Processing Agreement.
  • The uploaded conversions— we keep the transaction reference and the result Google returned, so we can show what was accepted and what was refused. Contact details are hashed before they leave our systems and are never stored in readable form.

Full detail is in the privacy policy and the list of sub-processors.

Consent

Nothing is uploaded for a visitor who has not granted advertising consent. Every row carries its own consent signal, and a row without an explicit grant is dropped rather than sent. The tags on your site are consent-gated too, so no click id is collected in the first place where consent was refused. The legal basis for the underlying data is yours as the controller; we act on the signal you give us.

What this does not do

It does not invent attribution. If a customer never clicked an ad, nothing matches and nothing is credited — there is no click for their invoice to be tied to. A large share of revenue in most businesses is genuinely not ad-driven, and this system leaves that share exactly where it is.

It also does not decide how often one click may be credited. That is a setting on the conversion action in your own Google Ads account (Count: every conversion or one), and it stays your decision.

How you can check it

Every upload is reconciled: we re-read what Google actually accepted, refused, or silently ignored, and show it per batch with the reason. That reconciliation is the point of the tool. If the match rate drops, you are told; if Google rejects rows, you see why rather than seeing a number quietly get smaller.