Privacy and data handling
Attribution touches your customers' contact details, so the honest version of this page is a list rather than a promise. Below is what Attribi holds, what leaves it and in what form, what your own connected systems receive, and the two things a privacy review will ask for that Attribi cannot do today. If you are assembling a processing register or answering a security questionnaire, this page is meant to be copied from.
No credit card required · 5-minute setup
Ask an attribution vendor what they store and you are shown a compliance page and a logo. What a privacy review actually needs is the field list: which identifiers are held, in what form, where they travel, and what happens when one person asks to be erased. That answer is rarely on the website.
Matching a closed deal back to a click works best with an email address, and every offline conversion API is built to receive one. Your legal team would prefer that address never left your systems in a readable form. Both positions are reasonable and they meet at hashing.
Erasure requests arrive rarely and then all at once. If a tool cannot delete one person on request, that fact should surface during procurement rather than during the request, when the clock is already running.
An email or phone number reaches Attribi either from a form submission on your site or from a record read out of your CRM. It travels over TLS. It is not hashed in the visitor's browser: hashing happens once it reaches Attribi's servers, and the page you are reading exists partly so nobody claims otherwise.
Attribi stores the address and the phone number on the lead record, together with SHA-256 hashes computed on arrival, inside your own workspace. Storing the raw value is what lets Attribi match the same person between your CRM and your website later. Not storing it at all is designed and not yet built, and it is listed below as such.
When a conversion uploads to Google, Meta, LinkedIn, TikTok, Microsoft or Snapchat, the identifiers in the payload are hashes, computed to each platform's own normalisation rules. Raw addresses do travel to the systems you connected yourself, because writing attribution onto your own CRM contact is the point of that integration.
Every offline conversion upload identifies the person with a SHA-256 hash, normalised the way the receiving platform requires. This holds for all six ad platforms and for every funnel stage. There is no setting that turns it off and no code path that sends an address in the clear.
The lead record holds the email address and phone number alongside their hashes, which is what allows the same person to be recognised across your CRM and your website. We would rather state that plainly than let "hashed" be read as "not stored".
Your CRM, your Google Sheet and your own webhook receive the contact details, because those are your systems and that is what you connected them for. Nothing goes to any other destination, and there is no data marketplace, no enrichment resale and no model trained on your data.
The tracker sets a first-party visitor cookie containing a random identifier and nothing else, marked HTTP-only, and a 30-minute session cookie. No third-party cookie is set, and no contact details are written to a cookie or to browser storage.
Email privacy@attribi.com and everything held for your account is deleted within 30 days, with confirmation. Disconnecting an integration stops further ingestion immediately. Both commitments are in the published privacy policy, not just here.
Planned, not live today. Listed so you can see what this does not do yet, before you sign up.
Not yet available. There is no endpoint and no button that removes or exports a single individual, so an erasure or portability request has to be handled by hand against your account. It is on the roadmap as data-subject APIs, with no date committed.
Not yet available.
Not yet available. Hashing on receipt, so that no raw email or phone is written to disk at all and your CRM stays the only place the readable value exists, is a designed architecture that has not been built. It is the largest single item on the roadmap and it carries no date.
Not yet available.
No script required
Run attribution with no script on your site. Attribi reads leads and revenue from your CRM and uploads the outcomes to your ad platforms.
Closing the loop
Send qualified leads and closed-won revenue from your CRM to Google, Meta, LinkedIn, TikTok, Microsoft and Snapchat, automatically, with no spreadsheet uploads.
CRM
HubSpot ad attribution in both directions: campaign data is written onto the contact your reps already read, and closed deal revenue is pulled back out.
CRM
Salesforce offline conversion tracking: won Opportunities upload to your ad platforms as revenue, matched on email and phone, using your own stage names.
Ad platform
Google Ads offline conversion tracking: send qualified leads and closed-won revenue from your CRM, so your account sees CRM-verified outcomes, not just form fills.
Ad platform
Meta Conversions API for CRM: send qualified leads and closed-won revenue from your CRM to Meta server side, with hashed email, phone, and Instant Form lead IDs.
Compliance describes your processing, not a vendor, so the useful answer is what Attribi does. For your visitors and leads, you are the controller and Attribi processes that data on your instructions. Attribi stores the contact details you send it, along with hashes; sends only hashes to ad platforms; does not sell data or train models on it; and deletes an account's data within 30 days of a request. What Attribi cannot do today is delete or export one individual on request, which is stated on this page rather than discovered later.
Yes. The lead record holds the email address and phone number as received, with SHA-256 hashes stored alongside them. The raw value is what lets Attribi recognise the same person between a CRM record and a website visit. Storing hashes only, so that no readable address is written at all, is designed and not yet implemented.
No. The tracking script sends the values it collects to Attribi over TLS, and hashing happens once they arrive. Hashing inside the visitor's own browser belongs to the same planned architecture as not storing raw values at all, and neither is live today. If a review question depends specifically on where hashing occurs, the accurate answer is: on Attribi's servers, on receipt.
The ad click ID where one was captured, SHA-256 hashes of the email address and phone number normalised to that platform's specification, the funnel stage, a timestamp, a deduplication key, and the deal value and currency on a closed-won conversion. No name, no readable address, no page history and no journey detail.
Today it is handled manually: contact privacy@attribi.com and the record is removed for you. There is no self-service per-person deletion or export in the product, which is a real gap and is listed on this page as planned. Deletion of everything held for your account is available on request and completes within 30 days.
In a managed Postgres database hosted on AWS, with each account's data scoped to that account. Attribi is operated from the United Arab Emirates by Techinfy IT Solutions, and depending on where you are, data will be processed in the regions our cloud providers operate. Region pinning for a specific jurisdiction is not offered today.
Updated
Connect your ad platforms and your CRM, and read the answer from your own account.
Start FreeNo credit card · Free forever up to 1,000 visitors