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 10 September 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.
barua uses these records to update that site's customer profiles. Accepting an import does not authorize an email. The site still needs permission 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.
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 permission to email the person, valid where that person lives. barua's acceptable use policy makes that a condition of using it at all.
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 identity and purchase evidence 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. Deciding and writing a message passes the distilled profile to a language model provider in the United States, and a second provider there receives site summaries for daily reviews and bounded retries, to learn what its pages mean and which messages are worth trying. 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, also in the United States, the way any email leaves any system.
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: nothing new starts after that moment, and an email already in the middle of being sent may still arrive, the way it does with any sender. There's also a hard floor between messages: barua never decides two for the same person within 20 hours (with longer cooldowns per kind of message), and it re-checks that gap at the moment of sending. 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. 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 the messages permanently, and it is worth being exact about what it does not do: 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.
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.
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 Mailgun for delivery. 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.