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, a purchase, a step in a client’s product designer such as starting a design, choosing one or adding it to the cart, or a visit to a client’s product or landing page and whether the visitor engaged with it by reading on, playing a video or staying a while), 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. Where the browser has no click cookie but the platform put its own click identifier in the address of the page the visitor landed on (Meta’s
fbclid), that identifier is passed on in the format the platform documents for exactly this case. These are the standard parameters for this kind of reporting.
Nothing else. No browsing history, no page-by-page behaviour beyond the specific steps a client has chosen to report, no message or enquiry content, no words or designs a shopper created, no payment details, and nothing about any other business. A shopper who has opted out of marketing in the store’s privacy settings is not reported at all.
A paid order from a product designer is reported once, from the store’s own order notification, using the contact details on the order (hashed as above) and the platform cookie values the shopper’s browser carried during the design. It is reported only if that shopper allowed marketing in the store’s privacy settings during the design; with no answer on record it is not reported. It is a separate event from the store’s own purchase reporting, so a sale is never counted twice.
Separately, a paid order is matched to the client’s own email campaigns (an order soon after a click on one of them), using only the store’s customer number. That count is kept inside LookSavi for the client’s reports and is never sent to an advertising account.
Customer lists
A client can also ask LookSavi to keep an advertising audience of their own customers in their own advertising account — for example to leave existing buyers out of ads meant for new ones. The list is built from the client’s customer records and sent as SHA-256 fingerprints of email address, phone number and name, never the values. It is refreshed about once a day and replaced each time, so someone who unsubscribes, whose email bounces or who reports a message as spam is removed from the audience on the next refresh.
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 guessed, and never taken from another page or another visit; the one identifier rebuilt is a click identifier the platform itself placed in the address of the page the event came from.
- 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.