What the barua pixel collects, what never leaves the visitor's browser, how long anything is kept, and how to be erased. Written for the owner of a site that runs barua, and plain enough for anyone who visited one.
Status: draft 1.0, version , prepared 19 October 2026. Not in force. The data processing agreement is the binding version of what this page describes, and it wins wherever the two could be read differently.
If you are reading this because a site you visited runs barua, the important thing first: that site is responsible for your data, not barua. They decided to collect it, they decide what it is for, and their privacy policy is the one that governs. barua holds it for them and does what they ask with it. In the language of the law they are the controller and barua is their processor.
That is why the erasure section further down tells you to ask the site first. It is also why barua will not answer a request about you on their behalf, beyond pointing you at them.
barua is responsible for its own business accounts and workspace invitations. That is the second half of this page.
barua records a masked replay of each visit so it can understand what a person was doing. In the replay, every input value and every piece of rendered text is replaced in the browser, before anything is sent.
One narrow edge to know about: a stylesheet loaded from another domain without CORS can render text out of your markup's attributes, and the browser will not let the pixel read that stylesheet to learn which attributes it uses. The pixel masks known text-carrying attributes and anything shaped like prose regardless; if your site uses such a stylesheet, keep personal data out of custom attributes.
The server double-checks its own bookkeeping too. When it cannot confirm which style rules applied to a stored piece of replay, it re-masks that piece fully instead of trusting the narrower first pass. If a re-mask attempt fails, the failure is recorded and retried on later visits. Whatever still cannot be repaired is removed with the replay itself: most of it on the normal thirty-day expiry, and the rare piece the bookkeeping cannot reach gets flagged for our operators to remove by hand.
Alongside the replay, the pixel sends plain events that name what was interacted with (a clicked control's label, capped at 80 characters) and what the page was about (the page's title, or a product's name with its price); those labels come from the page itself. Cart and order events a site publishes through its dataLayer travel with identity fields stripped and a 4KB cap (an oversized payload is reduced to its totals). Two things a visitor types do travel: the query when they use the site's search (read from the URL, capped at 120 characters), and the contact details covered in the next section.
Structured activity also includes page and visit references. Product identifiers distinguish
variants, and cart snapshots describe availability. Form progress can record a validation
failure or an explicitly reported completion. It records field types and validation codes,
not the field values.
Sites can report named application actions with a limited set of properties through
barua.track() or their dataLayer. We use this evidence with the site's product
guidance to assess possible obstacles and prepare useful follow-up suggestions. A missing
event is not treated as proof that an action failed.
An iframe's contents are never recorded, and an element the site marks with
data-cg-block gets the same treatment: the replay keeps only an empty
placeholder (the element's tag, class, width, and height). URL
parameters whose names mark them as credentials or as typed
content (an access token, an email a form wrote into the address) are scrubbed out, in the
query string and in the fragment. Each scrubbing rule applies from the day it ships. Replays
stored under earlier rules age out on their own within 30 days; older activity-log rows keep
what they arrived with for as long as the store keeps its log.
When someone changes accounts, the tag starts fresh anonymous and session IDs. Activity already queued keeps its original owner. Older versions recorded links between identified people who shared a device. Those earlier links may still supply the other person's email address when a message is being written. They do not supply that person's activity, and the writer is told never to use it.
Each visit also records the shape of the device it happened on: the window size, whether it is
a phone, tablet or desktop, whether the screen is touch, the browser's language and its timezone.
And how the person arrived the first time: the full address they came from, scrubbed of anything
shaped like a credential or a typed value and capped at 300 characters, so its path travels too
and not only the site's name; a plain label for what kind of source that was; the path they landed
on, scrubbed the same way; the utm_ parameters on the link; and the click identifiers
that ad platforms add, from a fixed list rather than whatever is in the address.
Two things run outside the London pipeline rather than in it, though not necessarily outside London itself. The first is fetching the barua script, and who fetches it decides where that lands. Most sites let the browser fetch it from us, and it is served from whichever of our host's locations is nearest that browser, so our host sees the connection and the address it came from. Some sites serve the script from their own domain instead: then their server fetches from us and the nearest location is the one nearest that server, which may well be London. In that arrangement our host sees the server rather than the person, unless the site's proxy is configured to pass the visitor's address along in a header, which some do by default. Ask the site if that matters to you; it is their setting, not ours. We ask browsers and proxies to keep the file for an hour, so it is usually not fetched again on the next page, though a reload or a proxy with its own rules can fetch it sooner.
The second is the location lookup, and it survives the first arrangement entirely: the browser makes it directly to us even on a site that serves the script itself. It is meant to happen once a session, and it is skipped once an answer has been stored, so a visit that fails to get one, or that opens tabs at the same moment, can ask more than once. It turns that connection into a country code, a country name, a region and a city. Neither writes the address into our database; the visitor's IP is never stored. Script error messages travel as the page's own code emits them, trimmed to 200 characters with emails and long numbers redacted first; an error that quotes what someone typed can carry that text.
Contact details a visitor is actively giving the site are captured in the clear: the email in a newsletter popup, the name on a checkout form. barua picks them up only at the moment the form or popup actually sends, whether the visitor clicks its button or presses Enter. Typing alone never counts as an identity. The same handover happens when the site already holds the details and passes them through its dataLayer, the way shop platforms announce a signed-in customer.
A site that wants none of this automatic pickup puts data-auto-identify="off" on
its tag, and barua then only learns an email when the site passes it explicitly.
Where the server integration is enabled, a site can send customer records without a pixel visit. These contain its customer identifier and email address, with account or activity timestamps when supplied. Purchase records contain the site's order identifier, the customer it belongs to, the purchase time and update time, and whether it has been paid. Refunds and voids are recorded too.
A site can also send events from its server. An event is a named fact about one of its customers, like an account being created or an order shipping, with the time it happened and its details. barua defines a fixed set of core events, such as a signup or a shipped order, and the details each one can carry. Any other event is one the site declared, with its details, in an event plan its owner approved. A signup carries the person's email, and can also carry details such as their first name, their answer about marketing email, their language and their time zone. Order events can carry what was bought and what it cost, and shipping events can carry tracking details and an expected delivery date. A title of something a person made can name someone else, like a child a book was made for.
Each detail is marked as one an email may quote or one used only for deciding: barua marks the details of its core events, and the site marks the details of its own. Receipts and order updates quote the order's own details, like the amount and the tracking number, and code fills those in with no model involved. Every other email a play sends can quote only details marked for emails. An event that does not match the plan keeps only the reasons it was refused, and its name when the name itself is valid, never its values. It stays with its import receipt, which the site can read for seven days and which is then removed as described under "How long data is kept" below. Events sent with a test key are checked and never stored against a person.
barua uses these records and events to update that site's customer profiles and to decide which of the site's approved plays a person is in. Accepting an import does not authorize an email. The site still needs permission or another lawful basis to write to the person, and the existing sending checks still apply. Receiving and applying these records does not call a language model. Information derived from them can become part of the profile used to decide on a message, as described below.
Each day, retrying hourly until that day's check has run to the end, barua also compares the purchases the pixel saw with the ones the site's server reported, and tells its own team when the server seems to have missed some. That note carries visit ids and times, never a name or an email address.
Once a person is identified, what the pixel saw them do on the site joins their profile: the pages and products they viewed, what they read, what they searched for on the site, and how recently and how often they visit. barua can use that profile, together with what the person made on the site, to shape the words of the emails the site sends them. Erasing the person removes it with the rest of their profile.
No cookies. The pixel keeps the following values in the browser's localStorage, scoped to the one site:
| Key | What it holds |
|---|---|
cg_aid | an anonymous id for this browser, on this site only |
cg_sid | the shared session's id; an identified page keeps its own session context in memory |
cg_last | when the shared session was last active; an identified page uses its own activity clock. After 30 quiet minutes, the next activity starts a new session. |
cg_consent | the visitor's consent answer |
cg_tags | which set of tags that answer covered, so adding one later asks again |
cg_first_touch | how they first arrived: the referrer, the landing path, campaign parameters, and when |
cg_geo_sid | a note that the city lookup already ran this session |
cg_identity | a SHA-256 marker used to detect an account change; it does not hold the original email or account id |
cg_context | the tag key, current anonymous id, session id, and hashed identity marker, shared with tabs that have not identified their own account |
cg_outbox | a prefix for queued activity batches, with the tag key and batch id added to each storage key |
Queued activity batches contain the structured events awaiting delivery, including contact details when an identity event is queued. Session replay is not stored in this queue. The queue holds at most 1 MiB per tag and retries for up to 24 hours. It removes acknowledged batches. Expired entries are excluded from retries and removed the next time the tag is allowed to run, including entries saved under an older tag key. Closing the browser can leave them on the device until that next run. Storage limits or disabled storage can cause events to be lost.
One more value can appear briefly in sessionStorage: cg_sblk, written when a
search form the site marked with data-cg-block submits, so the results page knows
to keep that search private too. It holds the name of the search field and a timestamp, never
what was typed; the next page reads and clears it, and if no navigation happens it is
cleared within seconds.
On a site running consent-required mode, none of these are written before the visitor
answers. A refusal writes exactly one, cg_consent, so the refusal itself is
remembered, and a withdrawal after an earlier yes clears the rest.
Consent withdrawal clears saved activity under every tag key on the same site. It also clears pending activity in other open tabs when they receive the browser's storage notification. Requests already sent cannot be recalled.
Two modes. By default the pixel runs from the first pageview. With
data-consent="required" on the tag, it captures nothing and writes nothing to the
device until the site's consent banner calls barua.consent(true). One narrow
exception: if the site's own code calls barua.identify() before the answer, that
identity waits in memory, goes out only on a yes, and dies with the page otherwise. A
barua.consent(false) stops the recorder, clearing both the queue and the stored
values; the refusal marker is the one thing kept. When consent arrives, barua reads what the
page has already published (its dataLayer included) and starts from there. The grant also
restarts the activity clock at that moment: however long the page sat open before the visitor
answered the banner, the quiet wait does not count against the session, and another tab opened
right after joins it. A session left over from more than thirty quiet minutes is replaced with
a fresh one at the yes; a session still active within that window simply continues.
Which mode a site runs is the site's decision, and it is a legal one. Storing anything on a visitor's device, localStorage included, needs consent under the rules that apply across the EEA and the UK, unless it is strictly necessary for something the visitor asked for. A site with visitors there should be running consent-required mode and wiring its banner to it. barua ships the switch and says so in the install guide; barua cannot tell from its side whether a site flipped it.
The install page shows the wiring.
The site running barua has to have a lawful reason to collect what it collects, and it is theirs to have, not barua's. In practice there are two, and most sites will rely on both:
For the messages themselves, the rule is simpler and older: the site must have the person's permission to email them, or another lawful basis, valid where that person lives. barua's acceptable use policy makes that a condition of using it at all.
This is a different choice from the pixel consent above. A play is a rule-based email sequence a site runs through barua, and barua counts every email a play sends as marketing, except a receipt or an order update for an order the person placed. barua sends one of those only when the site's owner has approved that kind of email, and it sends it without marketing consent, because it is about an order the person placed. Its wording is written once for the site and approved by the site's owner. Every order detail is filled in from the order.
A marketing email goes to someone whose latest choice, as the site recorded it, is yes.
The site passes that choice along when the person signs up and again whenever it changes
(the marketing_opt_in flag on its signed_up and
consent_updated events), and the newest one counts. When two of the site's records
share an email address, the newest choice across them wins. Someone with no recorded choice is
treated as a no, unless the setting below is on.
The site's owner can state, in barua's settings, that the site has another lawful basis for writing to people who never said yes or no. With that setting on, barua also sends to someone with no recorded choice. It never covers someone whose latest choice is no: a no always wins, with the setting on or off. The setting starts off, and the site answers for that basis, as it does for everything it sends.
Once the site records a no, barua starts no new marketing email for that person, and one still waiting for approval can no longer be approved. An email approved before the no is withdrawn too, unless barua is already sending it at that moment. The unsubscribe link in each marketing email works as described under "If barua wrote to you" below. Email written by barua's older one-at-a-time writer, which is being retired, does not go through this check.
Server imports wait in a processing queue. Each record's supplied values are removed from that queue when processing finishes for it, including when it fails or is cancelled. Pending records stay until processing finishes or they are cancelled. Erasure removes identifiable queued values too. Cancelling an import does not undo records already applied to a profile.
Compact import receipts and hashed request metadata expire seven days after the receipt finishes. They are no longer available through the integration API after that point. A bounded cleanup removes the stored metadata; an outage or backlog can delay that physical removal. Applied evidence from the site's server, events included, follows the person's profile retention, not the seven-day receipt window. Erasure also removes identifiable queued records and the per-person version records used to reject duplicate updates.
Session replays are deleted after 30 days, and 30 is a hard ceiling rather than a setting that could be raised. The sweep that removes them runs hourly and is bounded, so a large backlog can leave one a little past its date until the next run reaches it. What barua works from after that is the distilled profile it wrote, like "came back to the same jacket three times", plus the plain activity log (which pages, which products, when, for how long). The profile is what decides whether an email would help.
A site can also report email-link visits from its own server, so a click still counts when the tag never ran. That report is one scrubbed page address and a time. It carries no name and no name, and the token in the address links it to the email it came from, which is what counting the click means, so it does resolve back to the person that email was written to. It is kept until the person it belongs to is erased: erasing a person removes the reports their email clicks created.
The activity log is kept while the site's account is open, and a fixed maximum age for it is being introduced. Everything else, with the reason for each period, is in Annex 4 of the data processing agreement. The one item worth repeating here: an address that has unsubscribed stays on a suppression list indefinitely, because remembering it is the only way to keep honouring the request.
The database and the stored replays, with every piece of the pipeline that reads them, run in London. That is outside the EU, which is why this page says London rather than "the EU". It is covered by the European Commission's adequacy decision for the United Kingdom, renewed in December 2025 and running to December 2031, so data reaching it from the EEA needs no standard contractual clauses and no transfer assessment, the same as if it sat in Frankfurt.
Several moments reach outside that storage, and all of them are named in the subprocessor list with the company doing them. No language model decides on or writes the message one person gets: barua fills that person's details into an email template. A language model provider in the United States writes those templates from the site's brand and its plays. barua tries each new template on a few real profiles, and when one fails, the note barua sends the provider to fix it can quote one of their details, such as the title of something the person made, which can name a child. A second provider there receives site summaries when learning is needed. Routine reviews of page and event meanings start no more often than weekly. Setup or an explicit refresh can start one sooner, and a review can take several bounded batches or retries. Reviews of which messages to try run when their inputs change. That summary carries no names or contact details as fields, and it does carry the playbook the site's owner wrote and a sample of up to fifteen real titles of things people made. Those two are free text, so whatever someone typed into them travels as typed, and a title can be personal in itself. The subprocessor list spells out every field. If a site's owner connects their own database, the shape of that database travels to a model provider in the United States once per mapping run: table and column names, types, key relationships, and summary statistics, so the model can propose how that schema maps onto barua's feeds. No row values make that trip. The script that collects the shape runs inside the owner's own database and is written so nothing a row contains can leave it. Sending a message hands the recipient's address and the message to our delivery provider: Mailgun in the United States, or Amazon SES in Stockholm after the announced migration. The recipient's own mail provider receives it next. AWS also processes delivery reports and forwarded template emails. The subprocessor notice period applies before customer data moves.
Profiles stay within the account that supplied the data, including records from that business's server. barua does not combine different customers' accounts or share their data with data brokers.
barua does not train models on any of this. Not its own models, not in aggregated form, not in de-identified form. The providers above are barred by contract from training on what they are sent. If that ever changes, it changes by us saying so first.
Our landing page runs the same tag it describes, with barua's own key, and it is the only page here that does: this privacy page and the pricing page carry no tag, so reading them is not captured and you are not asked for anything. On the landing page the tag captures nothing until you allow it, your typing is masked in the browser before anything leaves your device, and what is built stays scoped to this site and stored in London, like everything else here.
The early-access form is separate from that choice. If you fill it in and send it, the website and email address you typed reach us whatever you told the tag, because sending a form is you asking us to have them.
One thing follows from doing both. If you allowed the tag and then send the form, we attach the address you typed to the profile the tag had been building for this visit, so what was anonymous becomes yours by name. Decline the tag and that does not happen: the form still reaches us, and there is no profile to attach it to.
If you ask for early access, the website and email address you type are stored so a person can reply to you. On this public site that is the only thing you type that we keep. Signing in to the app at barua.ai/app is a different matter: an account there stores what you enter to run it, including your sign-in details and your sender settings.
We keep it until you ask us not to. It has no expiry, because it is one side of a conversation we are having with you, and putting a period on it that nothing enforces would say more than we can keep. Write to chris@barua.ai from that address and it is deleted.
Two emails go out the first time you ask, and both are emails, so both leave through our delivery provider like any other: the confirmation to you, and a note to us carrying the same website and address so a person knows to reply. Ask again from the same address and your early-access record is left exactly as it was: no second row, no replacement of what you first sent, and neither message goes out again. If you allowed the tag, sending the form still tells it your address each time, the same as the first time. That is the same exception described above and is not pinned to London. The record itself is stored in London with everything else.
Every marketing email barua writes for a site has one-click unsubscribe, and unsubscribing sticks: no new marketing email starts after that moment, and an email already in the middle of being sent may still arrive, the way it does with any sender. Receipts and order updates carry the same link, and it stops marketing email only: they keep coming after you unsubscribe, and each one says so beside the link. Marking an email from the site as spam stops every email barua writes for that site, receipts included, and so does an address that no longer exists. There's also a hard floor between messages: barua never decides a marketing message for someone within 20 hours of the last message it decided for them, a receipt included (with longer cooldowns per kind of message), and it re-checks that gap at the moment of sending. Receipts and order updates don't wait for that floor, so one can arrive soon after another email. Hearing from a site often means something is wrong, and we'd want to know: chris@barua.ai.
A reply we send you directly, like the confirmation for an early-access request, carries no unsubscribe link, because it is one message answering something you asked for and there is no list behind it to leave.
To have your data erased, ask the site you visited, or write us from the address in question. Erasure is keyed by email. A site can also erase someone from its own server, with one call naming the customer id it gave barua and one naming their email, so the address barua last heard and their current one both go. An anonymous visitor's replays expire on their own after 30 days.
You can also ask for a copy of what is held about you, ask for something wrong to be corrected, or object to being written to. Objecting stops every email barua writes to you for that site, receipts and order updates included, for as long as the site keeps the record of your objection. It does not stop the site recording your visits, so ask for erasure as well if that is what you want. Those requests go to the site as well, since they are the ones who owe you an answer, and barua assembles what is held and hands it to them, normally within five working days of being asked.
One record survives on purpose: the erased address goes on the suppression list, keeping that address off every future send from the site you asked. Each site keeps its own list, the same way each site keeps its own profiles. Short-lived operational traces that carry an address, like the record that spaces outgoing email, clear on their own within two days. Delivery-attempt records retain opaque references, provider outcomes and one-way address fingerprints for late delivery reports. Erasure removes those fingerprints immediately; workspace deletion removes its attempt records. Platform-email address fingerprints clear with their short-lived address traces.
This part is about you rather than your visitors, and here barua is the controller.
barua holds the email address you sign in with and the sign-in itself, which workspaces you belong to and your role in each, what you have got through in setup, your site's address, your sending domain, the briefing and brand details you wrote, and the billing record. It also holds the record of which version of these documents you accepted, when, and the address and browser you accepted them from, because an agreement nobody kept a record of is not much of an agreement. It also holds the operational trail of your account running: what the pipeline did, what it cost, what failed.
If you create a server integration key, barua stores its hash and identifying prefix, the label you give it, who created it, and its creation or revocation time. The database does not store the key's secret. These administrative records remain while your account is open.
An owner-authorized agent connection adds its label, granting owner, permissions, review policy, expiry and revocation details, plus the hash and prefix of its management key. Barua records the actions it requests, their configuration inputs, review decisions and outcomes, with the connection policy version. These records support access control and safe retries. They also provide an audit of changes. Connections and their action records, including revoked or expired connections, remain until the granting account or workspace is deleted. Tracking plan and play approval history remains with the workspace. An agent approval keeps the agent's identity and delegated authority even after the granting account is deleted.
Pending agent work expires after seven days. An erasure request's customer identifier is removed when the action completes or is cancelled. It is also removed on expiry and when that person is erased through another path. Expiry cleanup is bounded and can lag during an outage or backlog. Delivery verification links an event to its admitting key and the approved play, then to the message and provider's delivery report. It stores references and times; deleting the underlying event removes its verification record. Customer reads and erasure need separate permissions. If you give your own agent access to customer data, its provider processes the data under your arrangement with that provider.
That data is used to run the service for you, to bill you, to answer you when you write in, and to keep the thing working. The basis is our contract with you, and for security and the operational record, our legitimate interest in running a service that does not fall over. We keep it while your account is open, then delete it within 30 days of the account closing, with two exceptions we would rather name than bury: the accounting records Norwegian law makes us keep, and the record of which version of these documents you accepted. That last one is the evidence of the agreement itself, so deleting it while a claim could still be brought would leave neither of us able to show what was agreed. It is kept for five years after the account closes, which matches the accounting records, and then goes with them.
If a workspace owner invites you, they give barua your email address. This record exists even if you do not have a barua account. It identifies the workspace and inviting owner, and includes the invitation dates and status. We also store the delivery result and a hash of the invitation token. The address and invitation email pass to the email delivery provider named in our subprocessor list. We use these records to deliver invitations and manage workspace access. They also help enforce sending limits. Our basis is our legitimate interest in managing access to the service.
An invitation expires after seven days. Expiry or revocation does not delete its record: we retain it until the invitation record or its workspace is deleted. There is no automatic deletion after expiry. To request removal of an invitation addressed to you, write to chris@barua.ai. If you accept, the separate record of your agreement follows the five-year retention period above.
We do not sell it, and we do not send you marketing you did not ask for. You have the same rights over it that your visitors have over theirs, and the address to use is chris@barua.ai.
Then almost nothing happened. This site sets no cookies, runs no analytics, and loads nothing from another company: the typeface is served from here, and so is every image. There is no banner to click because there is nothing to consent to.
Our hosting provider keeps ordinary server logs, which include IP addresses, for a short period, and that is the whole of it. If you email us, we keep the email so we can answer it.
Everything goes to chris@barua.ai, and a person answers. barua is operated by barua AS in Norway (registration pending; the org number and address land here on incorporation).
If we get it wrong and you are not satisfied with how we handled it, you can complain to the Norwegian Data Protection Authority (Datatilsynet), or to the supervisory authority where you live. If the complaint is about a site that runs barua rather than about barua, it belongs with that site's own supervisory authority, and we will help you work out which that is.