A companion to the Privacy Policy, describing one specific data flow: what LookSavi sends to a client's own advertising account when that client asks us to measure their advertising. Written for a client and their advisers, and checkable against the software.
What this is for
When a business advertises online, the advertising platform can only improve the advertising it shows if it knows which of its ads produced a result. The browser is an unreliable place to report that: ad blockers, tracking prevention, poor networks and closed tabs all lose events, and some results — a renewal, a sale completed over the phone — never happen in a browser at all.
So LookSavi can report a conversion from the server instead. It is the same event the business already knows about, sent once, to an account the business controls.
It is off unless a client turns it on
There is no default. A connection has to be created, given the client’s own advertising credentials, told which specific events it may send, and then enabled. Until all four are done it sends nothing, and a connection that allows no events sends nothing however it is configured.
What is sent
For each conversion, only what identifies the event and the person:
- The event — what happened (for example a form submission or a purchase), when it happened, the page it happened on, and where relevant the amount and currency.
- Matching information, so the platform can recognise a customer it has already seen: email address, phone number, name, city, region, postal code, country, and the business’s own customer reference. Each of these is hashed with SHA-256 before it leaves. The platform receives a fingerprint, not the value.
- Technical values the platform requires unhashed and which cannot be hashed without becoming useless: the visitor’s IP address, their browser’s user-agent string, and the platform’s own cookie values where the visitor’s browser already carries them. These are the standard parameters for this kind of reporting.
Nothing else. No browsing history, no page-by-page behaviour, no message or enquiry content, no payment details, and nothing about any other business.
What is never sent
- A cookie value that was not there. Where a platform’s own identifier is absent, it is left out. It is never reconstructed or guessed.
- An identifier we are unsure of. A value that does not pass its format rule is omitted rather than corrected — a confident guess is worse than a gap, because afterwards it cannot be told apart from a correct value.
- One client’s data to another client’s account. Where an event may go is decided from the source it arrived on, on our servers. Nothing in a web request can redirect it.
- Anything from a restricted client. Some businesses — a health service, for instance — are marked restricted, and then no destination may be attached and no event may be sent, whatever else is configured. Hashing an identifier does not make the underlying information safe to send.
How long identifiers are kept
Seven days, then they are deleted. That is not a habit, it is arithmetic: an advertising platform will not accept an event more than seven days after it happened, so past that point the matching information cannot be used for anything and keeping it would be pure risk. While it is held it is encrypted.
The record that an event happened, and whether it was sent, survives without the identifiers. That is deliberate: it is what lets us answer “how many enquiries did we accept last Tuesday, and how many reached the platform”, which is the question that catches the failure nobody notices — reporting that quietly stops working while every screen stays green.
Consent
An event is only sent if something recorded that the person agreed: a consent choice on the client’s own website, a tick box they checked on a form, or their store platform’s own consent signal. The decision is stored with the event, as it stood at the moment of capture.
If nothing recorded a decision, the event is not sent. It is kept, marked as suppressed, and never delivered. A missing consent signal is treated as a refusal, not as a silent yes, and a decision made later never authorises an event captured earlier.
Who receives it
Today, one platform: Meta, through its Conversions API, into a dataset the client owns in their own Meta Business Manager, using credentials the client issued and can revoke. LookSavi does not hold an advertising account that receives client conversions.
How to switch it off
Any of these, and each of them works:
- Ask us. We disable the connection and it stops sending.
- Remove our access in your own advertising account. This needs nothing from us and we cannot prevent it.
- Where the website side is a plugin, deactivate it.
Disabling a connection stops sends and leaves the record of past events intact, so nothing already reported becomes unexplainable.
Questions, and requests about your information
Write to hello@looksavi.com. The general policy, including access and deletion requests, is at Privacy Policy.
Contact
Questions about this document, or a request about your information: hello@looksavi.com.