GDPR and the Meta Conversions API: Hashing, Lawful Basis and How Long to Keep Lead Data
Is SHA-256 hashing enough to send customer data to Meta under GDPR? Who is controller and processor, lawful basis, the DPA and how long to keep lead data.
On this page
- Who is who when data goes to Meta?
- Is SHA-256 hashing anonymisation?
- Which lawful basis covers sending data to Meta?
- Do you need a data processing agreement?
- How long should you keep lead and customer data?
- Which safeguards should you check in a tool?
- Checklist before you switch sending on
- What the tool will not do for you
Hashing does not take you outside the GDPR. SHA-256 turns an email or phone number into a string Meta can match to an account, so legally it is still personal data, just better protected in transit. To send leads and orders through the Conversions API you need four things: a lawful basis, a privacy notice, a data processing agreement with your tool vendor, and a sensible retention period. This guide covers each one, with links to the regulation and to Meta's own documents.
This is not legal advice. It organises the facts and explains what the tool does. Decisions on lawful basis and retention belong to the data controller, ideally made with a lawyer or your data protection officer.
Who is who when data goes to Meta?
Your business is the controller: it decides why and how customer data is processed. A tool that receives leads and sends them to Meta on your behalf is a processor. Meta's role is set out in its Business Tools Terms and depends on the purpose.
| Party | GDPR role | Where it comes from |
|---|---|---|
| Your business | Controller | You collect the leads and orders and decide the purpose |
| Tool vendor (e.g. Convs) | Processor | Processes data on your instructions, not for its own purposes |
| Meta Platforms Ireland: matching and measurement | Processor | Business Tools Terms, section 5.a.i |
| Meta Platforms Ireland: event data collected on your site with Meta's tools | Joint controller (Article 26) | Business Tools Terms, section 5.a.ii and the Controller Addendum |
The European Data Protection Board explains these concepts in its Guidelines 07/2020 on controller and processor. The key test: a processor does not pursue its own purposes. A vendor that used your customers' data for something of its own would stop being just a processor.
Meta's terms also put obligations on you. You state that you have a lawful basis to share the data and that your customers received a clear notice about how it is collected and used.
Is SHA-256 hashing anonymisation?
No. The GDPR defines pseudonymisation as processing data so it can no longer be attributed to a person without additional information (Article 4(5) GDPR). Recital 26 adds that pseudonymised data that can be attributed to a person with additional information is still personal data. A hashed email fits that definition exactly: the same address always yields the same hash, and Meta can match it precisely because it holds hashes of its users' addresses.
In January 2025 the EDPB published draft Guidelines 01/2025 on pseudonymisation that point the same way: pseudonymisation reduces risk but does not take data out of scope.
So why hash at all? Because Meta requires it, and because it genuinely protects data in transit: someone who intercepts an event does not see the address. Meta lists the preparation rules in its customer information parameters reference:
| Field | Before hashing | Hashed? |
|---|---|---|
Email (em) | trim leading and trailing spaces, lowercase | yes |
Phone (ph) | digits only, with country code, no symbols or leading zeros | yes |
First and last name (fn, ln) | lowercase, no punctuation | yes |
IP address (client_ip_address) | the customer's real address | no, Meta says it must never be hashed |
User agent, fbp, fbc | values from the browser | no |
lead_id | the Meta lead form ID | no |
Convs normalises and hashes email and phone on the server before an event enters the delivery queue. Phone numbers must include a country code (for example +44…), and an invalid email stops the event with a clear error rather than sending junk. The Meta Conversions API feature page has the technical detail.
Which lawful basis covers sending data to Meta?
The GDPR allows processing on one of the grounds in Article 6(1). In marketing, two are common:
- consent (point a): the customer knowingly agrees to their data being shared for advertising; they can withdraw it, and you must be able to prove it,
- legitimate interests (point f): requires a balancing test, weighing your interest (measuring and optimising ads) against the customer's rights, plus a right to object.
Separately, ePrivacy rules on cookies and device access cover the Pixel and browser identifiers. In practice, marketing scripts run only after consent is collected by a consent management platform (CMP).
Three cases worth writing down separately:
- A Meta lead form submission. Filling in a form is not automatic consent to further processing. Check your form wording and the privacy policy link.
- A status from a Google Sheet. The consent column should reflect a real decision or a real lawful basis, not be ticked in bulk.
- A shop order. Browser data (
fbp,fbc, IP, user agent) comes from the customer's device, so it needs their marketing cookie consent.
In Convs, every event requires a lawful-basis confirmation (consent=true), or it never enters the queue. A Meta form can only be connected after an organisation admin confirms the lawful basis. The shop collector stores nothing and sends no requests until your CMP passes consent, and it clears local state when consent is withdrawn. The tool forces the question; you supply the answer.
Do you need a data processing agreement?
Yes, whenever an outside company processes your customers' data on your behalf. Article 28 GDPR requires a contract setting out the subject matter, duration, nature and purpose of processing, the types of data and categories of people, and the processor's duties, including:
- acting only on your documented instructions,
- confidentiality for anyone with access,
- security measures under Article 32,
- rules for using sub-processors (with your authorisation),
- helping you handle data subject requests and breach notifications,
- deleting or returning data when the service ends,
- providing the information you need for audits.
A DPA should be signed before you upload customer data to any tool. Convs signs one with every customer, on every plan, before processing starts. The Custom plan only adds negotiable DPA terms, an SLA and self-hosting (Convs is a single program you can run on your own infrastructure). Compare plans on the pricing page.
How long should you keep lead and customer data?
The GDPR sets no number of months. The storage limitation principle (Article 5(1)(e)) only says data must not be kept longer than the purpose requires. Your job is to choose a period, record why, and delete automatically rather than "at some point".
Meta draws some lines of its own: the Conversions API accepts events up to 7 days old, and lead form data can be retrieved for 90 days. Keeping raw event payloads for months "just in case" serves no purpose.
In Convs, the organisation owner or an admin sets the retention period: 6 to 120 months, 24 by default, counted from a person's last activity. Every night the hub deletes people inactive for longer and writes the count to the system log. A person can also be deleted by hand from their record, which requires typing a confirmation word.
| Removed when a person is deleted | Kept after deletion |
|---|---|
| the person's data and history, plus records merged into it | Meta lead IDs and their stages (to avoid duplicate events) |
| lead form submissions and event contents | hashes of numbers on the "Do not SMS" list |
| automation run data | event fingerprints, without contents |
| unsent events to Meta (they are cancelled) | an audit log entry |
Shorter limits apply regardless of that setting:
- event payloads are deleted after 30 days,
- contact details stored on the form submission itself are deleted after 30 days (the person stays in the CRM under the retention period),
- personal data in automation runs and steps is encrypted and deleted after 30 days.
The "Do not SMS" list deliberately survives deletion: you must not start texting a number that asked you to stop. It holds only hashes of numbers. More on the CRM on the CRM feature page.
Which safeguards should you check in a tool?
Article 32 requires security "appropriate to the risk". For a tool holding leads and ad account tokens, ask your vendor at least these questions:
| Question | How Convs handles it |
|---|---|
| Are tokens and data encrypted? | OAuth tokens, Meta tokens, secrets and event payloads are encrypted with AES-256-GCM |
| Are businesses kept apart? | Every record belongs to one organisation, and the server checks membership on every request |
| Who sees what? | Roles: owner, admin, operator, viewer. Viewers see masked phone numbers and emails and no SMS text |
| Do logs contain customer data? | Delivery logs do not store raw event payloads or error responses |
| What about backups? | Backups have their own retention and include data from before cleanup, so set that period separately |
The full list is on the security page.
Checklist before you switch sending on
- Document the roles: controller, processor, Meta's role.
- Choose a lawful basis for each data source and record the reasoning (for legitimate interests, the balancing test).
- Update your privacy policy and form wording: data may be shared with Meta to measure and optimise ads.
- Sign a DPA with your tool vendor before uploading customer data.
- Set the retention period and add it to your record of processing activities.
- Start in test mode with a test event code from Events Manager, and only then enable production sending.
If you send data from a spreadsheet, read offline conversions from Google Sheets to Meta too, and for which fields actually help matching, see the guide to Event Match Quality.
What the tool will not do for you
Convs takes care of the technical side: it hashes, encrypts, requires a lawful-basis confirmation and deletes data on schedule. It does not replace the controller's decisions. Specifically, it:
- does not assess your lawful basis or run a balancing test,
- is not a consent management platform and does not write your privacy policy,
- cannot recall data Meta has already accepted: deleting a person only cancels events not yet sent, and an event already in flight at that moment may still arrive,
- does not shorten backup retention if you run your own backups on your own server.
If your organisation does not want any customer data to leave its infrastructure, the Conversions API is the wrong fit, whatever tool you use. Otherwise, a well-documented process plus a tool that enforces it is a reasonable balance. If you are just starting, read what the Meta Conversions API is first.
Frequently asked questions
Is a hashed email address personal data?
Yes. SHA-256 turns the address into a fixed string, but the same address always produces the same hash, and Meta matches it against hashes of its own users' addresses. The GDPR calls this pseudonymisation (Article 4(5)), and Recital 26 says pseudonymised data is still personal data.
Do I need customer consent to use the Conversions API?
Not always, but you always need a lawful basis under Article 6 GDPR and a privacy notice. Most businesses rely on consent or legitimate interests. Cookies and the browser Pixel need consent under separate ePrivacy rules. The decision belongs to the controller, ideally with legal advice.
Who is the controller of data sent to Meta?
You are: the business that collects the leads and orders. Under Meta's Business Tools Terms, Meta Platforms Ireland acts as your processor for matching and measurement, and you are joint controllers for event data collected on your site with Meta's tools (Article 26 GDPR).
How long can I keep lead data?
The GDPR sets no number of months. It requires that data is kept no longer than necessary for its purpose (Article 5(1)(e)). Pick a period, document why, and delete automatically. In Convs you set it between 6 and 120 months, 24 by default.
Does deleting a person in Convs also delete what was sent to Meta?
No. Deletion erases the data in the hub and cancels events that have not been sent yet, but it cannot recall what Meta has already received. Likewise, withdrawing consent in the shop collector does not withdraw conversions sent earlier.
