Privacy Manager: how visitors can remove their personal information

Privacy regulations give people the right to ask that their personal information be removed, and they expect you to act on that request quickly. The Privacy Manager gives your visitors a secure, self-serve way to make that request, and gives you a controlled way to act on it, without your legal team handling each one by hand.

In short: The Privacy Manager does not delete, it disconnects. A visitor verifies who they are and asks to be removed. Once you approve, Bread & Butter severs the link between that person and their behaviour on your site. The journey stays, detached from any individual, which is why your reporting does not develop holes and your Focused Score model keeps learning. The research profile, assembled from public web sources, is not destroyed either. What ends is the connection between the two. This applies to data held in Bread & Butter, so if you have synced that person into Salesforce, HubSpot, or your own database, we notify you by API that a request has been made and you decide what happens to those copies.

What de-identification actually does

Most systems answer a removal request by deleting a row. That solves one problem and creates another, because every report that person ever appeared in quietly changes.

The Privacy Manager takes a different approach. It does not delete. It disconnects.

For any identified visitor, Bread & Butter holds two separate things:

A research profile, built from publicly available web sources: who the person is, their role, their company, company news and background. This is Deep Profile Enrichment.
A journey, the record of what happened on your website: page views, conversion events, session timings, and the sequence of steps taken.

De-identification severs the link between them. The journey remains in your account, detached from any individual. The research is not destroyed. What ends is the ability to say that this particular person did this particular thing on your site.

That is the distinction worth understanding before you set this up, because it is what separates the Privacy Manager from a delete button, and it is also what you will need to explain if a visitor or a regulator asks you exactly what happened to their data.

What happens to your analytics and your ICP

This is the part that makes the approach unusual, and it matters more than it first appears.

Because the behavioural record survives, your aggregate statistics stay accurate. Page views, conversion events, and traffic flow all still reflect what actually happened on your site, so your historical trends do not shift every time someone exercises their rights.

It also means your Focused Score model keeps its training data. The patterns that taught the model what a serious buyer looks like on your site are behavioural, not personal, so removing the identity does not cost you the lesson. Your Ideal Customer Profile carries on working with the same evidence base it had before.

What we can reach, and what only you can

Bread & Butter can only act on data held in Bread & Butter. This is worth understanding properly, because it is where most of the real work sits.

If you have synced an Intelligence Brief or a profile into Salesforce, HubSpot, your data warehouse, or any other connected system, that copy lives outside our platform and we have no way to scrub it. What happens to it is your decision and your responsibility.

To make that manageable, we expose an API notification: when a de-identification request is made, Bread & Butter can tell you or a third-party application that it has happened, so your own systems can act on it rather than waiting for someone to remember.

Where this fits in your compliance obligations

The Privacy Manager is built to aid your compliance. It does not deliver compliance on its own, and any tool that tells you otherwise is overselling, because compliance depends on what happens across your whole business rather than inside one platform. We do our part, and the rest is yours.

A verified, auditable route: When a visitor asks to be removed, you have a workflow that confirms it really is them, records the request, and severs the connection on your approval. Whether that disconnection satisfies a particular legal request is a judgement for you and your counsel, because it depends on what you hold about that person in Bread & Butter and everywhere else.
A standing, self-serve path: Regulations including the GDPR and CCPA/CPRA expect people to be able to make this kind of request without friction. The Privacy Manager gives them one that runs without your legal team touching it.
ePrivacy Directive: Visitors get a clear, standing route to withdraw consent at any time, which is what the tracking and cookie consent rules expect you to provide.
Verified opt out: A security PIN sent to the visitor's verified email address ensures only the actual owner of the data can trigger the process, which protects you against both malicious requests and accidental data loss.
Trust, not just compliance: Telling visitors up front that they can disconnect themselves from their browsing history at any time is worth more to your brand than the legal cover it provides.

Setting up the Privacy Manager

The process has four stages. Bread & Butter handles the verification and the disconnection; you keep control of the final approval.

Step 1: The trigger

Give visitors a way to start the process. There are three ways to do it, and any of them can sit on a button, a footer link, or a line in your privacy policy.

WordPress: If your site runs on WordPress, set the trigger up through the Bread & Butter plugin interface. Nothing needs to be added by hand.
URL parameter: On any platform, link to a page running the Bread & Butter library and add ?action=deidentification to the end of the URL. The Privacy Manager widget opens when the page loads. No coding required, it is just a link.
JavaScript: To open the widget from an existing element, call it directly:

BreadButter.widgets.deIdentification();

Step 2: The request

The visitor is shown the widget and asked to prove who they are, either by authenticating or by confirming with a PIN sent to their verified email address. Once they authenticate, their status moves to pending de-identification.

Step 3: Your approval

You receive a notification in your Opportunities view. Review the request there and approve it. Requests do not process on their own, so this needs to be part of someone's routine rather than something noticed later. Erasure requests carry legal deadlines, and the clock does not wait for an approval.

Step 4: De-identification

On approval, the link between the person and their journey is severed. The journey stays in your account with nobody attached to it, and the research profile is retained separately, as described above. If you have set up the API notification, your other systems are told at this point.