GDPR and the Meta Conversions API: Hashing, Lawful Basis and How Long to Keep Customer Data

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 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 orders 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.

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:

Basketly 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:

1. A phone order or an order from another channel. Placing an order is not automatic consent to marketing. Sending the purchase for ad measurement needs its own lawful basis, described in your privacy policy.
2. A status from a Google Sheet. The consent column should reflect a real decision or a real lawful basis, not be ticked in bulk.
3. A shop order. Browser data (fbp, fbc, IP, user agent) comes from the customer's device, so it needs their marketing cookie consent.

In Basketly, every event requires a lawful-basis confirmation (consent=true), or it never enters the queue. Connecting a shop through its API (Shoper, IdoSell, BaseLinker) requires the person setting it up to confirm 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. Basketly signs one with every customer, on every plan, before processing starts. The Custom plan only adds negotiable DPA terms, an SLA and self-hosting (Basketly is a single program you can run on your own infrastructure). Compare plans on the pricing page.

How long should you keep 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. Keeping raw event payloads for months "just in case" serves no purpose.

In Basketly, 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.

Shorter limits apply regardless of that setting:

• event payloads are deleted after 30 days,
• 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 customer data and ad account tokens, ask your vendor at least these questions:

The full list is on the security page.

Checklist before you switch sending on

1. Document the roles: controller, processor, Meta's role.
2. Choose a lawful basis for each data source and record the reasoning (for legitimate interests, the balancing test).
3. Update your privacy policy and checkout wording: data may be shared with Meta to measure and optimise ads.
4. Sign a DPA with your tool vendor before uploading customer data.
5. Set the retention period and add it to your record of processing activities.
6. 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

Basketly 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.