Privacy Policy

This policy explains what personal data Pixelary processes, why, where and for how long. Pixelary handles two kinds of personal data, in two different roles:

• Our customers’ data (people who sign up for Pixelary, use the dashboard or the Framer plugin, or join a team). For this data we are the controller. Sections 3–5.
• Data about visitors of our customers’ websites, which the Pixelary script collects and sends on our customers’ behalf. For this data the website owner is the controller and we are the processor. Sections 6–9.

1. Who we are

Pixelary (pixelary.app) is provided by Oleksii Ukrainskyi, a sole proprietorship (jednoosobowa działalność gospodarcza) entered in the Polish business register CEIDG, ul. Ceramiczna 5c/58, 03-126 Warszawa, Poland, NIP 5242785728, REGON 521840030 (“Pixelary”, “we”, “us”).

Contact for privacy questions and requests: hello@pixelary.app.

We have not appointed a data protection officer; write to hello@pixelary.app about anything in this policy.

2. The short version

• Pixelary moves conversion events from websites to Meta, TikTok and ChatGPT Ads (OpenAI). The website owner decides which platforms receive them.
• Contact details that the script picks up on a website (email, phone, name and similar) are normalized and hashed with SHA-256 in the visitor’s browser, before they leave the page.
• The script follows the visitor’s consent choice: without it, no advertising pixel loads and no data goes to our servers or the platforms. In the EEA, the UK and Switzerland it waits for a yes; elsewhere it treats consent as given unless the website or the visitor says otherwise (section 6.4). The older Framer plugin tag (framer.js) works differently (section 6.8).
• Our code does not store visitors’ IP addresses or user agents. Our servers pass them to the advertising platform with each server-side event, as the platforms use them for matching. Cloudflare, which runs our servers, processes them to deliver each request (section 3.9).
• Our database (Supabase, AWS region eu-west-1, Ireland) and the per-site event log (Cloudflare Durable Objects with EU jurisdiction) are stored in the EU. Requests are handled at the Cloudflare location nearest to the visitor, which can be outside the EU (section 11).
• The event log on paid plans keeps 30 days (1-site and 5-site plans) or 90 days (10-site plan). It holds no contact details and no IP addresses.
• We do not sell personal data.

3. Customer data: what we process and why

3.1 Your account and sign-in

You sign in with Google or with a code sent to your email address. Sign-in runs on Supabase Auth.

• Sign-in with Google: we receive your email address and the profile details Google shares, which are your name, your profile picture URL and your Google account ID. We do not get access to your Gmail, Drive or any other Google service.
• Sign-in with an email code: we store your email address. The sign-in email holds a one-time code and a sign-in link. It is sent by Supabase through Mailgun (EU region).
• Account records: your user ID, the sign-in methods you used, when the account was created and when you last signed in.
• Framer plugin sign-in: the plugin opens a sign-in page on our server. After you sign in, our server holds the session tokens for up to 10 minutes in Cloudflare Workers KV until the plugin collects them.
• Sessions: the dashboard and the plugin keep your session in your browser’s local storage (section 10.2).

Purpose: to create and secure your account and let you sign in. Legal basis: Art. 6(1)(b) GDPR (performance of the contract).

3.2 Your sites and their settings

For each site you add, we store:

• the site’s name, its site key (a public ID such as px_8f2kq), the platform it is built on, and its domains (production and staging);
• for sites connected through the Framer plugin, the Framer project ID and the domains Framer reports for the published site;
• the pixels you connect: platform, pixel ID, a label, test event codes, live or test mode;
• access tokens and API keys for the Conversions APIs (Meta, TikTok, ChatGPT Ads);
• triggers (which page views, clicks, forms, bookings and scroll depths count as events, with names, values and parameters), consent defaults and site settings (default country for phone numbers, visitor ID settings).

Access tokens and keys are stored in database tables that only our server can read with the service key; the dashboard and the plugin can see only whether a token is present, never its value. When you save a Meta token, our server checks it with Meta before storing it. When you save a ChatGPT Ads key, our server sends OpenAI one test event marked validate_only. Our server keeps a copy of each site’s configuration, tokens included, in Cloudflare Workers KV for up to 5 minutes so it does not query the database for every event.

If you press Send test event in the dashboard, our server sends one test PageView to the platform you chose, with your own browser’s IP address and user agent, as a real server event would carry them.

Purpose: to provide the service you configure. Legal basis: Art. 6(1)(b) GDPR (performance of the contract).

3.3 Subscription and billing

Payments are handled by Lemon Squeezy, our merchant of record. Lemon Squeezy collects your card details, billing address and VAT ID, charges you, adds tax where it applies and issues invoices, under its own privacy policy.

When you start a checkout, we pass Lemon Squeezy the internal ID of the site (and its Framer project ID for sites from the plugin) so the payment is linked to the right site. From Lemon Squeezy we receive and store the subscription ID, its status and the end of the current billing period. We never receive or store card numbers; Lemon Squeezy handles payment details.

Purpose: to sell and manage subscriptions, and to switch server-side delivery on and off according to the plan. Legal basis: Art. 6(1)(b) GDPR, and Art. 6(1)(c) GDPR for the records that tax and accounting law require us to keep.

3.4 Teams

On plans that include a team, the account owner can invite other people as Editor or Viewer; each account has one Owner. A Viewer sees events, stats and settings. An Editor can also change pixels, triggers, domains and settings, but not access tokens. Only the Owner handles access tokens, billing and the team. We store each member’s email address, role, the sites they can access, and the invitation’s status. Invitations are sent by email through Mailgun (EU region). The person invited receives an email from us that shows the inviter’s email address, the role (Editor or Viewer) and what it allows, and a sign-in link that works once and expires after 7 days.

If you invite someone, make sure they are happy to receive the email.

Purpose: to let several people work on the same sites. Legal basis: Art. 6(1)(b) GDPR for the account owner and members; Art. 6(1)(f) GDPR, the owner’s legitimate interest in inviting their team, for an invitation to a person who has no account yet.

3.5 Emails from us

We email you when you sign in, when you are invited to a team, and when we need to tell you about your account, billing, security or changes to our Terms or this policy. We send only these service emails. We do not send newsletters or marketing emails; if we ever start, we will ask for your consent first.

3.6 Support

When you write to hello@pixelary.app, we process your email address, the message and anything you attach, to answer you. Mail to hello@pixelary.app is forwarded by Cloudflare Email Routing to our mailbox at Google (Gmail), and we reply through Mailgun.

Legal basis: Art. 6(1)(b) GDPR for customers; Art. 6(1)(f) GDPR, our legitimate interest in answering the people who write to us, for others.

3.7 The Framer plugin, and Microsoft Clarity in the dashboard

The Pixelary plugin for Framer reads, through Framer’s plugin API, the ID of the Framer project you open it in and the addresses where the project is published. It writes the Pixelary script into your project’s custom code when you install it, and a small record of the last script change into the project’s plugin data, so it can tell when your change has been published and can put the previous script back if you ask it to. It also keeps the last site you opened in your browser’s local storage.

Earlier versions of the plugin loaded Microsoft Clarity as soon as they were opened and tagged each recording with the Framer project ID and the site’s domain; the current plugin does not load Clarity, and an older copy stops loading it once it is updated.

We use Microsoft Clarity, a product analytics tool from Microsoft, only in the dashboard (app.pixelary.app). It records how the dashboard is used: clicks, scrolling, mouse movement and what the page shows. Clarity loads only after you, once signed in, agree to it in a prompt. You can change your choice at any time in Settings. Recordings mask access tokens, API keys, site keys, email addresses and team lists. Sessions are identified by a hashed user ID, not by your email address. After you agree, Clarity sets the cookies _clck (1 year) and _clsk (1 day) on app.pixelary.app. Microsoft keeps recordings for 30 days and heatmap and usage data for up to 13 months, which is Clarity’s standard retention. Clarity does not run on pixelary.app or on our customers’ websites.

Purpose: to understand and fix problems in the dashboard’s interface. Legal basis: your consent, Art. 6(1)(a) GDPR. You can withdraw it at any time in Settings; this does not affect processing before you withdrew it.

3.8 Our website and the dashboard

pixelary.app does not load analytics, advertising or tracking scripts. The dashboard (app.pixelary.app) loads none either, except Microsoft Clarity, and only after you agree to it (section 3.7). Both are served by Cloudflare.

3.9 Technical logs

Our infrastructure providers process technical data such as IP addresses to deliver and protect the service. Cloudflare receives the IP address of every request to our website, dashboard and servers. Our servers do not write request logs to storage; we view live logs only while fixing a problem. Cloudflare keeps its own operational and security logs under its policies. Supabase keeps logs of requests to the database and the sign-in service: its API and sign-in logs, including IP addresses, are kept for up to 7 days.

Legal basis: Art. 6(1)(f) GDPR, our legitimate interest in running and securing the service.

4. Who receives customer data

• The sub-processors and service providers on our list, with their purpose and location, at https://pixelary.app/subprocessors: Cloudflare (hosting, processing, DNS and email forwarding), Supabase (database and sign-in), Mailgun (emails), Microsoft (Clarity in the dashboard, with your consent) and Google (our support mailbox). They process the data on our behalf.
• Google, when you sign in with Google. For Sign in with Google, Google acts as an independent controller under its own privacy policy. Google also hosts our support mailbox, as our provider (above).
• Lemon Squeezy, which sells the subscription to you as merchant of record. Lemon Squeezy acts as an independent controller for the payment and tax data it collects, under its own privacy policy. We send it only the site IDs it needs to link the payment to the right site (section 3.3).
• Meta, TikTok and OpenAI, but only what you connect: the pixel IDs and tokens you save are used to call their APIs, and a test event or a token check sends them the data described in section 3.2.
• Authorities, when the law requires us to disclose data.

5. Customer data retention

You can delete a site (its settings → Delete site) or your whole account (Account settings → Delete account) in the dashboard yourself. Deletion takes effect at once and cannot be undone: it removes the site’s settings, pixels, access tokens, triggers and domains, and its event log; an active subscription has to be cancelled first. Account settings → Download my data gives you a copy of your account data as a file. You can also write to hello@pixelary.app and we will do it within 30 days.

6. Website visitors: what the Pixelary script does

This section is for people who visit a website that uses Pixelary. The website owner decides whether Pixelary runs, which platforms receive data, and what counts as an event. The website owner is the controller and their privacy policy applies; Pixelary processes the data for them. To exercise your rights, contact the website owner first (section 12.2).

6.1 How Pixelary gets onto a website

The website owner adds one script, https://cdn.pixelary.app/s/<site key>.js, in one of three ways: a <script> tag, our Google Tag Manager template (section 8), or our Framer plugin. The file contains the script and the site’s public settings (which pixels are connected, the triggers and the consent defaults). It contains no tokens. The script sends its events to https://api.pixelary.app. Sites installed before October 2026 load the script from framer-capi.aukrainskii.workers.dev and send their events there; that address keeps working. All these addresses run on Cloudflare.

6.2 What the script reads in the browser

Depending on how the website owner has set it up, the script reads:

• the page: its address, the referring address, page views (including navigation in single-page apps), clicks on chosen elements, scroll depth;
• forms, when a form is submitted: fields it recognizes as email, phone, first name, last name, full name, city, postal code and country (by field type, name, label or value), and fields the website owner pointed it to. Other field values are read only to check the website owner’s trigger conditions on the page; they are not sent anywhere. Password and file fields are skipped;
• embedded booking and form tools (for example Calendly, Cal.com, HubSpot, Tally, Typeform): the confirmation message the tool sends to the page, and, where the tool includes them, the email, name and phone of the person who booked or submitted;
• “thank-you” page addresses, when the website owner maps URL parameters to fields (for example the email in a WebinarJam redirect). The script removes those parameters from the address bar before any advertising pixel sees the page;
• details the website’s own code passes through pixelary('identify', …), pixelary('track', …), a dataLayer push with the event pixelary, or the Google Tag Manager template: email, phone, first and last name, external ID, city, postal code, country, and event details such as value, currency, product IDs and order ID;
• advertising click IDs and browser IDs in cookies: _fbp, _fbc (Meta), _ttp, ttclid (TikTok), __oppref, __obref (OpenAI), and the click IDs fbclid and ttclid in the page address, only with consent (section 6.4);
• the visitor ID: Pixelary’s own cookie _pxl_vid, or a cookie of the website that the website owner names, only with consent (section 10.1);
• consent signals: the website’s cookie banner (Cookiebot, OneTrust, CookieYes, Usercentrics, Complianz, iubenda, Termly, Osano, CookieFirst, the Framer cookie banner), IAB TCF, Google Consent Mode in the data layer, and Global Privacy Control;
• technical signals: the browser’s time zone (to tell the region before consent; it is not sent), whether the browser reports automation (navigator.webdriver), whether a hidden anti-spam form field was filled, which other pixels and Pixelary tags are on the page, and how long the script took to load.

6.3 What the script does with it

• Hashing: before contact details leave the browser, the script normalizes and hashes them with SHA-256, once for each platform, because Meta, TikTok and OpenAI use different rules. A value that already is a SHA-256 hash is passed on as it is. The external ID (including the visitor ID) is hashed the same way. Our server accepts contact fields only in hashed form and discards anything else.
• Addresses: the script and our server remove query parameters that carry personal data from the page and referrer addresses before sending them: known parameter names (email, phone, name and similar) and any value that looks like an email address.
• Browser pixels: where the website owner connected them, the script loads the Meta Pixel (connect.facebook.net), the TikTok Pixel (analytics.tiktok.com) and the ChatGPT Ads pixel (bzrcdn.openai.com) in the visitor’s browser and sends events to them. These scripts belong to the platforms; once loaded, they collect data and set cookies under the platforms’ own terms. The script passes hashed contact details only to the ChatGPT Ads pixel; the Meta and TikTok pixels receive the event without contact details.
• Server copy (paid plans): the script sends a copy of each event to our server, which forwards it to the platforms’ Conversions APIs (section 7).
• Free plan summary: on sites without server-side delivery, the script sends one short summary per browser session when the visitor leaves (section 7.3).

6.4 Consent

The script uses the four Google Consent Mode types, whichever banner the answer comes from:

Before the visitor answers:

• When the visitor’s IP address is in the EEA, the UK or Switzerland (the country Cloudflare reports when our server delivers the script; the address itself is not stored), or the browser’s time zone is, nothing counts as granted until the visitor says yes, unless the website owner has set other defaults for these countries in the dashboard.
• Elsewhere, consent counts as granted unless the website’s banner, its Google Consent Mode defaults, the website owner’s settings in the dashboard or the visitor’s Global Privacy Control say otherwise. Global Privacy Control counts as a refusal of ad_user_data and ad_personalization until the visitor answers the website’s banner.
• Our server checks the visitor’s country again, from the country Cloudflare derives from the IP address, and drops a server event from the EEA, the UK or Switzerland unless ad_user_data was granted. This check applies to server events only; whether browser pixels load is decided in the browser, by the rules above.
• Events that happen before the visitor answers wait in the page’s memory. If the visitor accepts, they are sent with the time they happened; if the visitor declines or leaves the page, they are dropped.

On websites that use IAB TCF, the script reads the purpose consents (purposes 1, 3, 4 and 7). Pixelary is not a registered TCF vendor and does not check vendor consent.

Choosing a banner, the defaults and the legal basis is the website owner’s responsibility.

6.5 Bots

Our server drops events it identifies as automated: requests from user agents of crawlers, headless browsers and HTTP libraries; events from browsers reporting automation; forms with the hidden anti-spam field filled; PageView and ViewContent events from cloud and hosting networks (identified by the network number, ASN, of the IP address); and more than 60 events in one minute from the same visitor. For the last rule our server keeps a short hash of the IP address and user agent in memory for at most one minute; it is never written to storage.

6.6 Staging addresses

Events from a site’s staging addresses (for example *.framer.app or *.webflow.io) are sent to the platforms in test mode only.

6.7 Fair-use limit

Above 1,000,000 server events per site in a calendar month (UTC), server-side PageView events are counted but not forwarded to the platforms; they appear in the event log with the status “counted”. Other events are sent as usual.

6.8 The older Framer plugin tag (framer.js)

Sites installed with earlier versions of our Framer plugin may still run the older tag, framer.js. It works differently:

• it loads the Meta and TikTok pixel scripts when the page loads, without waiting for consent, and treats tracking as allowed unless the website calls ft.setConsent(false);
• it sets the cookie ft_external_id (a random ID, 2 years) and, when the address contains fbclid, the cookie _fbc (2 years), and passes ft_external_id to the platforms unhashed;
• it hashes email, phone, first and last name in the browser before sending them to our server, and passes the full page address to the pixels;
• our server forwards its events to Meta and TikTok without a country check.

Website owners still on this tag can move to the current script in the plugin. The older tag stays supported while live sites use it, with no fixed end date. We will give at least 60 days’ notice in the dashboard and the plugin before ending it, and we remove it once no site has sent an event with it for 30 days.

7. Website visitors: what our servers receive, send and keep

7.1 What a server copy contains (paid plans)

For each event: the site key, the event name and ID, the time, the page address and referrer (cleaned as in section 6.3), the trigger type, event details (value, currency, product IDs, order ID, custom parameters set by the website owner), hashed contact details per platform, the advertising cookie IDs (only with ad_storage), the consent state, which browser pixels fired, and automation signals. Our server also sees the visitor’s IP address and user agent, the country and network that Cloudflare derives from the IP address, and the Origin or Referer header, which must match one of the site’s domains.

7.2 Where it goes

Our server forwards each event to the platforms the website owner connected, using the owner’s own access tokens:

Meta, TikTok and OpenAI are not our sub-processors. The website owner chooses them and sends them data under the owner’s own agreements with them (for example Meta’s Business Tools Terms). What they do with the data is described in their own policies.

7.3 Free-plan session summary

On sites without server-side delivery, the script sends one summary per browser session, only with analytics_storage granted, and for a share of sessions set by us (currently every session; we may lower the share): the site key, the script version, how it was installed, whether each platform’s pixel loaded, the visitor’s ad_storage answer, which consent tool was found, the names of up to 20 conversion events of the session, the script’s load time, extra copies of the script on the page, and the install check of section 6.2. Our server adds the country Cloudflare derives from the IP address and records the website’s hostname. It contains no contact details, cookie IDs, IP address or page addresses, and nothing is sent to the platforms.

7.4 What we keep

The event ID can be set by the website (for example an order number), and custom event details are whatever the website owner configures. Website owners should not put contact details in them.

8. Data that passes through the Pixelary Google Tag Manager template

Our template in the Google Tag Manager Community Template Gallery (“Pixelary Conversion Tracking”) lets a website owner run Pixelary from their Tag Manager container.

• What the template passes to the Pixelary script on the page, depending on the tag’s settings: the site key; the event name; value, currency, content IDs, content type, content name, number of items, order ID, event ID and custom parameters; user data the website owner maps from Tag Manager variables (email, phone, first name, last name, external ID, city, postal code, country), as raw values; and the visitor’s Google Consent Mode state (ad_storage, ad_user_data, ad_personalization, analytics_storage) read through Tag Manager’s consent API.
• What the template itself does: it loads the script from https://cdn.pixelary.app/s/<site key>.js and places commands in the window.pixelary queue. It sends no network requests and sets no cookies of its own.
• What happens next: the Pixelary script handles these values exactly as described in sections 6 and 7: contact details are hashed in the browser and sent only with ad_user_data granted, pixels load only with ad_storage granted, and server copies go to our servers and on to the platforms the website owner connected.

9. Our role for visitor data

For visitor data we act on the website owner’s documented instructions under our Data Processing Agreement. We do not use visitors’ personal data for our own purposes. We use counts that identify no one (for example how many events failed, or what share of sessions had a blocked pixel) to run, bill and improve the service. These counts contain no identifiers and are not personal data.

10. Cookies and browser storage

10.1 Set by the Pixelary script on our customers’ websites

Browsers may shorten the lifetime of cookies set by scripts (Safari, for example).

The script also reads, but does not write, the platforms’ cookies _fbp, _ttp, __oppref and __obref, and the storage of supported cookie banners, to learn the visitor’s choice. The platform pixels that the script loads set their own cookies under the platforms’ terms. A developer can turn on debug output with ?pixelary_debug=1 in the address or pixelary_debug in local storage; the script only reads this flag.

The older framer.js tag sets ft_external_id and _fbc (2 years each) and keeps ft_pv (the last page view, to avoid counting a reload twice) in session storage (section 6.8).

10.2 On our own website, dashboard and plugin

• pixelary.app: no cookies.
• Dashboard: local storage for your sign-in session (Supabase), the last site you opened and whether you have seen the welcome screen. No cookies of its own. Only after you agree, Microsoft Clarity sets the cookies _clck (1 year) and _clsk (1 day) on app.pixelary.app (section 3.7).
• Framer plugin: local storage for your sign-in session and the last site you opened. Older versions of the plugin also load Microsoft Clarity, which sets its own storage (section 3.7).

11. International transfers

Our database is in the EU (Supabase, AWS eu-west-1, Ireland) and the event log is stored in Cloudflare’s EU jurisdiction. Other processing can take place outside the EEA:

• Cloudflare handles each request at the location nearest to the visitor or user, which can be outside the EEA. Cached site configuration (including access tokens) in Workers KV and Analytics Engine data are stored on Cloudflare’s network and are not limited to the EU.
• Cloudflare, Supabase, Lemon Squeezy, Mailgun, Google and Microsoft are companies based in the United States, or belong to groups that are.

Where personal data leaves the EEA, we rely on the EU-U.S. Data Privacy Framework where the recipient is certified under it, and otherwise on the European Commission’s Standard Contractual Clauses included in the recipient’s data processing terms.

Data that website owners send to Meta, TikTok and OpenAI is transferred under the website owner’s agreements with those platforms.

12. Your rights

12.1 Customers and other people whose data we control

Under the GDPR you can ask us for access to your personal data, correction, deletion, restriction of processing and a copy in a portable format; you can object to processing based on legitimate interests; and where processing is based on consent, you can withdraw it at any time without affecting earlier processing. Write to hello@pixelary.app. We answer within one month, as the GDPR requires. Before we act, we may ask you to write from the email address of your account, or to confirm the request from it.

12.2 Website visitors

The website you visited controls your data. Please contact its owner. If you write to us, we will pass your request to the website owner and help them answer it. We usually cannot link a request to you on our own: we store no contact details in readable form and no IP addresses.

12.3 Complaints

You can complain to a supervisory authority, in particular in the EU country where you live or work, or where the infringement took place. Our lead authority is the Polish Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Stawki 2, 00-193 Warszawa, uodo.gov.pl.

13. Security

We protect personal data with measures that fit the risk. The main ones are listed in Annex 2 of our Data Processing Agreement: hashing in the browser, encrypted connections, tokens that only our server can read, EU storage for the database and the event log, short retention periods and access limited to the people who run the service.

14. Children

Pixelary is built for website owners and businesses and is not directed at children. Customers must be 18 or older, and Pixelary must not be used on websites or pages directed at children under 16.

15. Automated decisions

We do not make decisions about people that have legal or similarly significant effects based solely on automated processing. Filtering out bot traffic (section 6.5) affects only whether an event is forwarded.

16. Changes to this policy

We will update this policy when our data handling changes, and change the date at the top. We will tell account owners about material changes at least 30 days before they take effect, by email or in the dashboard.