GDPR & Data Processing Agreement

This page sets out the data-protection commitment of BEO TECHNOLOGY SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ and the binding Data Processing Agreement (DPA) under Article 28 GDPR that applies whenever we process the personal data of your website visitors on your behalf through the SGTM.space Service.

1. Our GDPR commitment

When you use the Service, personal data of your Visitors (such as their IP address, user agent and the data your tags send) passes through our infrastructure. We process it only on your instructions and in line with the GDPR. In summary, we encrypt connections, restrict access, store only what the Service needs to run and bill (a request row without query parameters, for 90 days, with the transition described in section 6, and Google Cloud's standard request logs for 30 days), use only the sub-processors listed in Annex 2 and give 30 days' notice before changing them, report breaches within 48 hours, and assist you with data-subject requests, data-protection impact assessments and audits. The binding terms follow below, with the details in Annexes 1-4.

2. Definitions

"Controller", "Processor", "Sub-processor", "Personal Data", "Processing", "Data Subject" and "Personal Data Breach" have the meanings given in the GDPR. In addition:

• "Service" means the SGTM.space platform;
• "Organization" means an organization in the Service, which owns Containers, subscriptions and the invoice details;
• "Customer" means the Organization or, where a business (a legal person, an organizational unit or a natural person running a business) stands behind the Organization, that business;
• "Operator", "we", "us" means BEO Technology sp. z o.o. acting as Processor;
• "Container" means a Customer's container in the Service: its tagging and Better Loader hosts, its configuration at the edge and, where one is configured, its Tagging Server;
• "Tagging Server" means the Container's Google Cloud Run services running the server-side Google Tag Manager image: the tagging server and the preview server;
• "Worker" means the Operator's Cloudflare Worker that the traffic of the Container's hosts passes through;
• "Customer's Worker" means the code that serves the Same Origin Transport path in the Customer's own account: a Cloudflare Worker in the Customer's Cloudflare account or, where the Service offers it, a file the Service generates for the Customer's project on Vercel or Netlify (a "platform file");
• "Visitor" means a person visiting the Customer's websites or apps whose browser or device sends requests to the Container's hosts, including a tester in a Live Logs or Preview Mode session;
• "Visitor Data" means the personal data of Visitors processed through the Service.

3. Roles of the parties, Customer obligations and rights

With respect to Visitor Data, the Customer is the Controller and the Operator is the Processor. Where the Customer processes Visitor Data on behalf of another controller (for example an agency for its client), the Customer is that controller's processor, the Operator is a further processor, and the Customer ensures that its instructions and this DPA are consistent with its agreement with that controller. With respect to account, billing and login-security data, the Operator acts as a controller as described in the Privacy Policy.

Customer obligations. The Customer is responsible for the legal basis for processing Visitor Data, including the consents required for cookies and tags, for informing Visitors, and for what data its tags send. What the Tagging Server reads from a request, what it does with the data and which recipients it sends them to (for example Google Analytics, Google Ads or Meta) is decided by the Customer's Google Tag Manager container configuration. Recipients chosen in that configuration are the Customer's recipients, not the Operator's sub-processors. The same applies to Google for the requests of Same Origin Transport's built-in Google Tag Gateway (section 5): by enabling it the Customer instructs the Operator to pass these requests to Google, which receives them as the Customer's recipient under the Customer's own agreements with Google. The same applies to the provider of an AI assistant that a user of the Customer connects to the Service (section 5): the data the assistant reads goes to that provider as the Customer's recipient, on the Customer's instruction. The Customer informs testers before they join a Live Logs or Preview Mode session. Where the Customer uses its own Cloudflare account (the Same Origin Transport Worker, Google Tag Gateway), Cloudflare acts there under the Customer's own agreement with Cloudflare, and for a platform file Vercel or Netlify acts under the Customer's own agreement with that platform. The Customer's Worker, its routes and rules run in the Customer's account; the Customer keeps the Container's key secret (for a platform file, in the project's environment variables, never in the file), rotates it if it may have leaked, and is responsible for any changes it makes to that Worker's code.

Customer rights. The Customer gives instructions (section 7), receives information and may carry out audits (section 14), may object to a change of sub-processor (section 10) and may request deletion or return of data (sections 12 and 15).

4. Subject-matter and duration

The subject-matter is the processing of Visitor Data necessary to provide the Service for the Customer's Containers. Processing lasts for as long as the Customer uses the Service, plus the deletion period described in section 15.

5. Nature and purpose of processing

Handling requests at the edge. Every request sent to the Container's hosts reaches the Worker on Cloudflare's network. The Worker reads the Container's configuration, applies the add-ons the Customer enabled, adds the Visitor's country and region code for the Container's region-specific settings, and forwards the request to the Tagging Server. A Container can run without a Tagging Server ("web only"); the Worker then serves only Better Loader and the add-ons at the edge.

Tagging Server. Each Container with a Tagging Server has its own Cloud Run services (tagging server and preview server) running the server-side Google Tag Manager image, in which the GTM container configuration pasted by the Customer runs. The Tagging Server processes the content of requests (for example GA4 event parameters) according to that configuration. The Operator does not change it and does not use the data processed in it.

Request recording. For each counted request the Worker writes one row to Google BigQuery with the data listed in section 6. The rows are used to count requests against the Container's plan and bill them, to enforce the limit (once it is used up the Worker answers with status 429), to detect automated traffic, and to show the Customer usage statistics. Outside a Live Logs session, the Worker does not store request bodies, cookies or query parameters; it forwards them to the Tagging Server (for the built-in Google Tag Gateway, to Google), changing them only as described in this section. Section 6 describes the transition for rows written before this change.

Add-ons run only when the Customer switches them on, with one exception: Bot Filtering switches on by itself in its "Only flag" mode (it marks likely bots and blocks nothing) once the plan of a Container includes it, unless the Customer set Bot Filtering for that Container before, and the Customer may change its mode or switch it off at any time:

• Better Loader serves the GTM loader script and Google scripts from the Customer's host through the Worker; Cookie Extender, Request Proxy, Google Tag Gateway, Same Origin Transport with its built-in Google Tag Gateway, the dataLayer option of Bot Filtering and Live Logs require it;
• Cookie Extender reads the cookies sent to the tagging host and re-issues the cookies the Customer selects with a longer lifetime;
• Bot Filtering blocks or flags automated traffic and can pass the verdict to the Tagging Server in headers; the verdict (based on the user agent, browser headers and the network the request comes from) is determined for every request, also with the add-on off, and written to the request row; with its dataLayer option, Better Loader also puts the verdict in the page's dataLayer;
• Request Proxy rewrites tag request addresses in the browser to an encoded address on the Customer's host, and the Worker decodes them and forwards them under the original path;
• Request Enricher adds headers with location, network, device and browser details derived from the IP address and user agent; the IP address and detailed location only when the Customer enables detailed location;
• Preview Mode forwards, for at most 60 minutes, the requests matching an optional path and IP address filter with the GTM preview header, so that the Customer sees them in its server container's preview mode; without an IP filter this covers the requests of all Visitors;
• Google Tag Gateway runs in the Customer's Cloudflare zone or CDN, outside the Service; the Service guides the Customer through switching it on, checks the result and Better Loader loads GTM through that address;
• Same Origin Transport (where available) sends tagging traffic from a path on the Customer's site (on up to 10 hosts of the site) through the Customer's Worker to the Container. The Customer's Worker passes on the browser's request without Authorization headers, only cookies with allowed names (never cookies whose names start with __Host- or common session and sign-in cookies), and, in dedicated headers, the Visitor's IP address, the location Cloudflare or the Customer's hosting platform derives from it and the site's host and path. The Operator's Worker trusts these headers only when the SHA-256 hash of the Container key sent matches the stored one and, once the deadline of a minimum version in force has passed (below), the Customer's Worker is not older than that minimum; it then uses that IP address and location as the Visitor's in every function described in this section. Without a valid key the request is forwarded as unverified, with the address and the data centre location of the network the Customer's Worker runs on. By default the Operator's Worker trusts every version of the Customer's Worker; only for a real security issue in older versions may the Operator set a minimum version, with a deadline at least 30 days later that it announces to the Customer by e-mail and in the Service. From that deadline a request from a Customer's Worker older than the minimum is still forwarded, the built-in Google Tag Gateway included, but with the address and location the Operator's Worker itself sees (those of the network the Customer's Worker runs on) instead of the Visitor's IP address and location it sends, so processing that relies on them loses them until the Customer updates its Worker. Once the path has passed a check, the Better Loader script carries a client that, in the Visitor's browser, routes Google's measurement requests addressed to the tagging host (Google Analytics, Google Ads and Floodlight events, and fetching the cookies of a streamed answer) through that path; other requests, including fetch requests with a body in a Request object, stay on the tagging host; the client stores no cookies or other data in the browser and does not change the data sent. The Operator's Worker marks every answer to traffic through the path with a header by which the client recognises that the request reached it; without that header (except for answers to fetch requests that were redirected or that the page cannot read) the client sends the rest of that page view to the tagging host and may send the request there again. For 24 hours after the add-on is switched off, the Operator's Worker still trusts the headers of the Customer's Worker, so that traffic from tabs opened earlier keeps the Visitor's data.
• Same Origin Transport's built-in Google Tag Gateway (where available) serves Google Tag Gateway for the GTM container Better Loader loads, under a folder of the Same Origin Transport path (/{path}/{folder}/). The Customer's Worker passes these requests to the Operator's Worker, which serves them only for traffic whose key it verified and sends them to Google's gateway address for that container ({tag}.fps.goog): the GTM script (gtm.js), the Google tag (gtag.js) and Google's measurement and advertising requests (for example Google Analytics and Google Ads). The request address with its query parameters and the request body go to Google as the browser sent them (for example the event parameters of a measurement request). Of the browser's headers it passes on only User-Agent, Accept, Accept-Language, Accept-Encoding, Content-Type, Origin and Referer, and of its cookies only those with allowed names (Google's identifiers, never cookies whose names start with __Host- or the Live Logs cookie), and it adds the verified IP address of the Visitor (X-Forwarded-For) and the Visitor's country and region code. The Referer header goes to Google as the browser sent it: the full page address, which may include query parameters. Of Google's answer the Worker passes back only an allowed list of headers, cookies with allowed names and only scripts, JSON, raster images and plain text, never HTML; it passes on a redirect only under the same folder or to Google's own addresses, and it keeps no copy of these answers in its cache. On the hosts where the Operator's checks of the gateway pass, Better Loader loads GTM through it after its own clients. Google therefore receives the Visitor's IP address and location as it does with a standard Google tag installation; where the zone's Google Tag Gateway in Cloudflare hid the IP address ("Hide original client IP"), Google receives it once the built-in gateway takes over. Google receives these requests as the Customer's recipient (section 3).

Cloudflare connection (where available). Once the Organization connects a Cloudflare account, the Operator, on a user's instruction and after the user's confirmation, creates or removes DNS records (and, only after the user explicitly confirmed overwriting a named record that stands in the way at a name the Container needs, overwrites it, recording the full previous record in the change log and putting it back on Undo, when the user has the records the Operator set up removed, and when the Container is deleted with the option to remove those records, which the user chooses; no Visitor Data is involved), changes the Google Tag Gateway setting in the zone and deploys, updates or removes the Same Origin Transport Worker in the Customer's account. A Same Origin Transport Worker the Operator deployed this way may later be brought up to a newer version of its code without a new confirmation, but only in place: the same script and the same routes, with only the Worker's code (and its key on a key rotation) changed; each such update is recorded in the change log the Organization sees, and creating, moving or removing a route, a rule or a Worker always needs a preview and confirmation. New versions are rolled out in stages, each Worker checked after its update; when a check fails, the Operator may put back the code each updated Worker had before, in place in the same way and recorded in the change log. To keep such Workers up to date, the Operator renews the connection's access with Cloudflare once a week. Where Cloudflare offers the setting, the routes the Operator creates are set to pass requests on to the Customer's site without the Worker when the account's Workers request limit is reached (fail open). A Worker the Customer deployed itself from the downloaded code is never changed by the Operator. Where the Service offers it, when a route of the Customer's own Worker already serves the Same Origin Transport path, the Operator may point that route to its Worker (route takeover), only after a preview naming that route and that Worker and the confirmation of an administrator of the Organization; it never changes or deletes the Customer's own Worker script, the change log records which Worker the route pointed to, and when the Operator's Worker is removed ("Remove from my Cloudflare") the Service offers to point the route back to that Worker if it still exists. These actions do not involve Visitor Data; their log is described in the Privacy Policy. The connection's authorization code and tokens can pass, on their way to Cloudflare, through the Operator's Worker on Cloudflare's network, which neither stores nor logs them. When the Operator, on the Customer's instruction, sets up the Google Tag Gateway setting in a zone that has none or only an empty one, it leaves the "Hide original client IP" option as the zone has it and, where it is not set, off, so Google then receives the Visitor's IP address as it does with a standard Google tag installation. In a setting that already exists, whoever set it up, the Operator switches that option off or on only on the instruction of a user who may change the Organization's Cloudflare settings and after a preview of that one value, records the change in the change log and, on Undo, puts the previous value back; the Customer can also change it in Cloudflare. The setting covers every site in the zone. The gateway's traffic does not pass through the Service, and Google is the Customer's recipient there (section 3). Once Better Loader loads GTM through Same Origin Transport's built-in Google Tag Gateway, the Operator, on the instruction of a user who may change the Organization's Cloudflare settings and after a preview naming the zone's proxied hostnames and the Organization's other Containers in the zone, switches that zone setting off, changing only the value that switches it on, and on a later instruction switches it on again (Undo); it never does so on its own or in the zone of SGTM.space itself. Where the Service offers it: when the Customer switches the Google Tag Gateway add-on off and the connection may change the zone's setting, the confirmation offers to switch the zone's Google Tag Gateway off in the same way, whoever set it up there (pre-selected only when the zone holds no other site or Container of the Organization, otherwise not pre-selected and listing the zone's other proxied hostnames and the Organization's other Containers), affecting every site in the zone; on the Google Tag Gateway add-on's page, on the instruction of a user who may change the Organization's Cloudflare settings and after a preview naming the zone's proxied hostnames and the Organization's other Containers in the zone, the zone's Google Tag Gateway alone is switched off in the same way, whether the add-on is on or off (an add-on that is on stays on, unless Same Origin Transport's built-in gateway loads Google Tag Manager for the site, when it goes off), and switched on again on Undo; and when the Customer switches Same Origin Transport off, the confirmation offers to switch the zone's Google Tag Gateway back on (as Undo, restoring the Google Tag Gateway add-on) where the Operator had switched it off and, for a Worker the Operator deployed, to schedule the removal of that Worker, its routes and the cache rule once 24 hours have passed, which is cancelled if the add-on is switched on again, removes only what the Operator created and nobody changed since, and is logged. Nothing changes in Cloudflare unless an option is ticked, and every change is recorded in the change log. None of these actions involves Visitor Data.

Live Logs (where available). When the Customer starts a Live Logs session for a Container, we also capture the traffic of the testers who join it, for the duration the Customer chooses (15, 30 or 60 minutes), so that the Customer can see how its tags behave. A tester joins by opening the start link the Customer gives them: it shows the tester a page saying what is captured and until when, with a link to leave the session, and sets the _sgtm_dbg cookie on the Customer's site until the session's scheduled end. Only the requests of a browser that carries that cookie are captured, together with the server container's reports on those requests (section 6); nothing changes for other Visitors. Before starting a session, the Customer confirms in the Service that the testers know their requests are shown there; the confirmation and its version are recorded. What a session captures is shown to the Customer in the Container's Live Logs tab and is described in section 6.

Live Logs Enhance's server check (where available) involves no Visitor Data. Only when the Customer starts it, the Worker makes up one test request, a GA4 event with a measurement identifier that belongs to no real property, consent denied, the home page of the Customer's site as its page address and no user data, cookie or IP address of a person, and sends it to the Customer's server container, where the Customer's tags may pass it on to their providers like any other event. Of the server tag template's report on that request the Worker keeps only the template's version, the server container's identifier and version, the client's name, the number of tags and the identifiers and names of at most five tags that did not succeed (with any e-mail address in them masked), for at most 2 minutes, in Cloudflare Durable Objects (in Cloudflare's EU jurisdiction for a Container hosted in the EU); the Service stores the check's result with the Container. The request is not counted or recorded in BigQuery.

AI assistants (where available). A user of the Customer may connect an AI assistant to the Service through the Operator's MCP server; the assistant then acts as that user, with that user's access. When the assistant reads a Live Logs session, the Operator's Live Logs analyzer Worker on Cloudflare works out the session's summary or a filtered page of its events from the data the session's Durable Object holds, already redacted as described in section 6, and the Operator's application server reads that answer and passes it on to the assistant without storing it, with the platform's internal hostnames masked (the Container's Live Logs tab, by contrast, reads the session from the Worker directly in the user's browser). By having an assistant read a session, the Customer instructs the Operator to send that data to the assistant's provider, which receives it as the Customer's recipient under the Customer's own agreement with that provider, not as the Operator's sub-processor (section 10). The Operator's log of the assistant's calls holds no Visitor Data, never the session's data, the arguments or the answers: only the tool, the time, the result status, the duration, the request's method and path, the IP address and user agent the request came from, the user, the app and the Container. A Live Logs session or a Live Logs Enhance check the assistant starts is the Customer's instruction, like one started in the Service.

6. Personal data and data subjects

Categories of data subjects: the Customer's website visitors and end users, including the testers who join a Live Logs or Preview Mode session.

Categories of personal data processed through the Service:

• the Visitor IP address, read from the CF-Connecting-IP header and, for Same Origin Transport traffic, from the header the Customer's Worker sends, and passed on to Google by the built-in Google Tag Gateway;
• the request as the browser sent it: the address with its path and query parameters, the headers (including User-Agent, Referer and Host), the cookies sent to the Container's hosts, and the request body, that is the data the Customer's tags send (for example client, session and user identifiers, the page address and event parameters);
• HTTP method, status code, response size, duration and timestamp, and the request category (for example GA4, Universal Analytics, gtag.js, gateway for the built-in Google Tag Gateway, or other);
• the automated-traffic verdict (whether the request looks automated, the reason, and whether it was blocked);
• cookies read and re-issued with an extended lifetime by the Cookie Extender add-on;
• the Visitor's country and region code (for example US and USCA), derived from the Visitor IP address at the edge and forwarded to the Customer's Container with every request, whether or not an add-on is enabled, so that the region-specific settings of the Customer's server container work;
• approximate location and network data (country, region, city, postal code, coordinates, time zone and network) derived from the Visitor IP address at the edge, and device and browser details derived from the User-Agent, forwarded to the Customer's Container by the Request Enricher add-on; of these, the Visitor IP address, region, city, postal code and coordinates are added only when the Customer enables detailed location, apart from the country and region code in the previous item;
• for Same Origin Transport traffic: approximate location and network (country and whether it is in the EU, continent, region and region code, city, postal code, coordinates, time zone, and network number and name), derived from the Visitor IP address by Cloudflare in the Customer's zone or by the Customer's hosting platform (as far as it provides them) and passed on by the Customer's Worker, and the site's host and path; after verifying the key, the Operator's Worker uses this location instead of the one it derives itself and passes it on only as the previous items describe;
• for the built-in Google Tag Gateway: the request as passed to Google (its address with the query parameters, the headers listed in section 5, with the Referer header carrying the full page address and its query parameters, cookies with allowed names and the body of Google's measurement requests), the Visitor IP address and country and region code sent with it, and Google's answer, including the cookies with allowed names it sets;
• in Preview Mode: a tester's IP address the Customer enters as a filter.

What reaches the Tagging Server. The Worker forwards the request with the browser's headers, so the Tagging Server receives the data the browser sent. The Visitor IP address can reach it in standard proxy headers (such as X-Forwarded-For), whether or not the Request Enricher add-on is on, which adds it in a separate header only with detailed location. For Same Origin Transport traffic the Worker removes the forwarding headers added on the hop from the Customer's Worker and the X-SGTM-Site-* headers, and sends the verified Visitor IP address in the X-Forwarded-For header in their place (and, with detailed location, in the Request Enricher's header as described above).

What we store. A request row in Google BigQuery holds only: a row identifier, the Container, the date and timestamp, the request path without query parameters (for the Request Proxy add-on, the decoded original path, also without parameters), the host, the Referer header without query parameters and fragment, the user agent, the Visitor IP address as received, the method, status code, response size, duration, request category, the automated-traffic verdict, a Same Origin Transport marker (site_path: valid or auth_failed, only for requests carrying the Same Origin Transport key header), and an MD5 hash of the Container, timestamp, request address and IP address. Request bodies, cookies, query parameters and other headers are not stored. A request of the built-in Google Tag Gateway gets the same row, with the category gateway and the Referer header likewise without query parameters and fragment; outside a Live Logs session nothing else of it, of what it passes to Google or of Google's answer is stored, and the requests with which the Service itself checks the gateway's setup and health are not recorded (the website audit, which loads pages in a real browser, is recorded like any visitor). The Worker writes rows this way from the deployment of the version introduced together with version 1.4 of this DPA. Rows written earlier also contain the request address's query parameters and the full Referer header; they are deleted under section 15, like all other rows. Aggregated daily request counts per Container are stored in the Operator's database. Neither the country and region code nor the data the Request Enricher adds is stored: that data travels only with the request, to the Customer's Container for traffic to the Tagging Server and, for the built-in Google Tag Gateway (section 5), the country and region code to Google. The Preview Mode IP filter is stored in the Operator's database as a Container setting and, for the duration of a session, in the Worker's configuration. The location passed on by the Customer's Worker is not stored. When a request carrying the Same Origin Transport key header, other than the setup check's diagnostic probe, fails verification (of the key, the host, the path or the IP address), the Worker stores in its configuration store (Cloudflare KV) a marker for the Container with the time, the reason and the Cloudflare zone of the Worker that sent the request, if any, without any Visitor data; the marker expires one day after the last failed request it records. Google Cloud Logging keeps the request logs of the Cloud Run services (the Tagging Server and the preview server) for 30 days, Google's default setting: the full request address including its parameters, the Visitor's IP address, the user agent, the Referer header, the response status and the timing.

Live Logs sessions additionally process, for the testers only:

• the requests their browsers send to the Container's tagging and Better Loader hosts and through the Same Origin Transport path, including those of its built-in Google Tag Gateway, as the Cloudflare Worker receives them (address, headers and body, the body up to a size limit), what the Worker did with each request and the response it returned;
• where the page agent runs in the tester's browser (brought by Better Loader, or loaded by the web GTM tag template the Customer installs), what the page puts in its dataLayer and the tracking requests it sends, including those sent directly to Google, Google Ads, Meta or other advertising services;
• where the Customer installs the Live Logs tag templates in its GTM containers, which web and server tags fired for the events they report on and the event data the server container processed. The Worker adds an X-SGTM-Debug header, holding the session identifier and the request's identifier, to the testers' data requests it forwards to the Customer's Container, and the server tag template uses it to send its reports on those requests back to the Worker.

This data is redacted before it is stored: cookie values are kept only for tracking cookies (such as _ga, FPID, _gcl_*, _fbp and _fbc) and for the session's own _sgtm_dbg cookie, and every other cookie is shown only by its shape; Authorization, API-key and GTM preview headers, the Container key and location passed on by the Same Origin Transport Worker and GTM environment credentials in addresses are masked; IP addresses in the client IP headers (including the header in which the Same Origin Transport Worker passes on the Visitor's address) and in IP fields (such as ip_override) are kept with their last part hidden; values under a fixed set of keys for an e-mail address, a phone number, a first or last name, a street, postal code or city, or a user identifier (such as email, phone, first_name and user_id; a GA4 parameter such as ep.phone counts by its own name), every value of user-data objects, and plain e-mail addresses anywhere are replaced by a description of their shape (their kind and length, or the first characters of a SHA-256 hash), never the value. All other data, such as the user agent, page addresses, pseudonymous tracking identifiers and values under other keys, is kept as received. Captured data is stored only in a Cloudflare Durable Object for that session and is never written to BigQuery or to the Operator's database.

7. Processing on documented instructions

We process Visitor Data only on the Customer's documented instructions, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which we are subject; in such a case we inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest. The documented instructions are this DPA, the configuration of the Container and its add-ons in the Service (including the choice of the Container's region), the Customer's GTM container configuration, and instructions the Customer gives us electronically, including through an AI assistant a user of the Customer connects (section 5). We will immediately inform the Customer if, in our opinion, an instruction infringes the GDPR or other data-protection provisions. We do not process Visitor Data for our own purposes: the counting and billing of requests, the limits, the detection of automated traffic and the statistics described in section 5 serve to provide the Service to the Customer.

8. Confidentiality

We ensure that only persons who need access to Visitor Data to provide the Service have it, and that they are bound by confidentiality obligations.

9. Security of processing (Article 32)

We implement appropriate technical and organizational measures, listed in Annex 3, including: encryption of connections (TLS); separate Cloud Run services for each Container with a Tagging Server, with the traffic of the Container's hosts routed through the Worker; restricted access to the infrastructure providers' accounts and to Container data; data minimization (request rows without bodies, cookies or query parameters, kept for 90 days, with the transition in section 6); redaction of Live Logs data; and sub-processor vetting. Because Visitor IP addresses are stored as received, the Customer should take this into account in its own risk assessment. Live Logs data is redacted before it is stored (section 6), can be read only with an access token issued for that session, and is deleted when the session ends (section 15).

10. Sub-processors

The Customer grants general authorization for the Operator to engage the sub-processors listed in Annex 2. We give notice of an intended addition or replacement of a sub-processor at least 30 days in advance, by a notice in the Service and an e-mail to the Organization's administrators, together with the new version of Annex 2. Within that period the Customer may object on reasonable data-protection grounds. If we do not agree on a solution, the Customer may, before the change is made, terminate the Service to the extent the change affects it, without additional charges. We impose on each sub-processor by contract the same data-protection obligations as in this DPA, in particular to provide sufficient guarantees to implement appropriate technical and organizational measures. Where a sub-processor fails to fulfil its obligations, the Operator remains fully liable to the Customer for their performance (Article 28(4) GDPR).

DigitalOcean, LLC hosts no Containers; it provides the Frankfurt data centre of the Operator's application server (Annex 2) as Laravel's sub-processor. Hosting Containers on DigitalOcean again requires the notice described above. The recipients the Customer chooses in its GTM configuration, Google for the requests of the built-in Google Tag Gateway, the providers of the AI assistants the Customer's users connect and the Customer's Cloudflare account (section 3) are not sub-processors, and the providers the Operator uses as a controller (for example payments and e-mail) receive no Visitor Data.

11. International transfers

The Operator is established in Poland, in the EEA. The Worker runs on Cloudflare's global network: a request is handled in the data centre nearest to the Visitor, which may be outside the EEA, and the Worker's configuration, including the Preview Mode IP filter, is available in every data centre. The Tagging Server runs in the Google Cloud region the Customer chooses for the Container: europe-west1 (Belgium) by default, with us-east1 (USA) and asia-southeast1 (Singapore) also available. The Customer's choice of a non-EU region is its instruction to transfer data to that country. Request rows of all Containers, whatever their region, are stored in one BigQuery dataset located in the EU (multi-region). The Operator's application server and database are in Frankfurt (Germany). A Live Logs session of a Container hosted in the EU (its server runs in a region in an EU member state when the session starts) is stored in Cloudflare's EU jurisdiction; for any other Container, Cloudflare chooses where the session is stored, which may be outside the EEA. Annex 4 describes the transfer mechanisms for sub-processors outside the EEA.

12. Assistance to the controller

Taking into account the nature of the processing, we assist the Customer by appropriate measures to respond to requests from data subjects, and to comply with the Customer's obligations under Articles 32-36 GDPR (security, breach notification, data-protection impact assessments and prior consultation). The Service does not identify Visitors, so a person's request rows can be found only by data the Customer provides (for example an IP address and a period). On the Customer's request sent to the address in section 13, we will find and delete such rows of the Customer's Containers, or hand over a copy of them, within 30 days. In the Service, the Customer can switch add-ons on and off, choose which cookies the Cookie Extender re-issues, choose whether the Request Enricher forwards detailed location, change or remove the Preview Mode IP filter, stop a Live Logs session, which deletes what it captured, rotate the Same Origin Transport key and delete a Container.

13. Personal data breaches

We will notify the Customer without undue delay, and in any event within 48 hours of becoming aware, of any Personal Data Breach affecting Visitor Data, by an e-mail to the Organization's administrators. The notice contains the information required by Article 33(3) GDPR as far as it is available at that time, and we provide the rest without undue delay as it becomes known. The Customer reports a suspected breach and data-protection matters to us at [email protected].

14. Audits

We will make available information necessary to demonstrate compliance with Article 28 GDPR and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates, on reasonable prior notice, subject to confidentiality and to reasonable limits on frequency and cost. We may rely on third-party certifications and reports, including those of sub-processors, where appropriate.

15. Retention, return and deletion of data

Retention during the Service. Request rows in BigQuery, including the Visitor IP address and user agent, are retained for 90 days. A daily job deletes the rows of days older than 90 days once they are included in the aggregated daily request counts, so a row can stay up to about 92 days after it was written; if the job cannot run, or the daily counts have not been taken yet, the rows are deleted at the next successful run. The request logs of the Cloud Run services in Google Cloud Logging are kept for 30 days (section 6). The marker of a failed Same Origin Transport verification expires one day after the last failed request it records. After deletion only the aggregated daily request counts per Container survive: a number of requests per Container, per day, per request category (also the number of automated and blocked requests), containing no IP address, user agent or any other identifier relating to a Visitor. Those aggregates are no longer personal data and are kept indefinitely as the basis of usage figures and invoices. The Preview Mode IP filter is removed from the Worker's configuration when the Customer switches Preview Mode off, and after the session expires (at most 60 minutes) by a job that runs every minute; the Worker does not apply it after the session expires, and after an earlier switch-off from the moment the change is written to its configuration. The filter stays in the Operator's database as a Container setting until the Customer changes or removes it.

Live Logs. What a Live Logs session captures is deleted when the Customer stops the session, at once or within a minute, and at the latest when the session expires, at most 60 minutes after it started. Only a marker that the session has ended, without any captured data, remains for two hours, so that late requests are refused. The Operator's database keeps only the session's metadata (who started it and when, the Container, the duration, the page address entered, the host and the session cookie's domain, the encrypted access token, the storage jurisdiction, when and why it was stopped, and the confirmation with its version), without any captured data, and deletes it 90 days after the session's scheduled end.

Container deletion and end of the Service. When the Customer deletes a Container, the Service removes its Cloud Run services (where it has any), custom hostnames and Worker configuration. Request rows are not deleted separately: they are deleted after 90 days as set out in the first paragraph, and the Customer may request their earlier deletion. We close an account on a request sent by e-mail, within 30 days. At the end of the Service, at the Customer's choice made before deletion, we will return a copy of the request rows of the Customer's Containers or delete Visitor Data (request rows, the Preview Mode IP filter and the Worker configuration) within 30 days, unless retention is required by law. Aggregated daily counts may be kept, as they are not personal data and substantiate invoices. We will certify deletion on request.

16. Liability

Liability under this DPA is allocated in accordance with Article 82 GDPR; the Operator is liable for sub-processors as set out in section 10. The limitation of liability in the Terms & Conditions applies to the extent permitted by law and does not limit the rights of data subjects.

17. Conclusion, changes and precedence

This DPA is governed by Polish law and the GDPR. It is concluded at account registration: by accepting the SGTM.space documents, the user also accepts this DPA, and the accepted versions and date are recorded. A user who creates an Organization or acts in one in the Service concludes this DPA on behalf of the Customer and represents that they are authorized to do so. An enterprise customer may ask for a copy signed by both parties.

Changes. We give notice of material changes by a notice in the Service and one e-mail; they bind existing Customers 14 days after the notice, and new Customers from their acceptance. Changes required by law or favourable to the Customer apply from publication. Continued use of the Service after that date means acceptance of the changes; a Customer who does not accept them may terminate the Service before then. Changes of sub-processors follow section 10.

This DPA prevails over the Terms & Conditions on matters of personal-data processing. The Polish version prevails; the English version is a translation, and the other language versions of the site show the English text.

18. Annexes

Annexes 1-4 form part of this DPA.

Annex 1: details of processing

Subject-matter and duration: section 4. Categories of data subjects: Visitors, including testers (section 6). Nature of processing: receiving, forwarding, recording, counting and deleting data, continuously for as long as the Service is provided.

Operation	Data	Purpose	Location	Retention
Handling requests at the edge (Worker)	IP address, the whole request (address with parameters, headers, cookies, body), country and region code	Delivering requests to the Tagging Server, add-ons	Cloudflare, the data centre nearest to the Visitor	Not stored
Tagging server and preview server (Cloud Run)	The request forwarded by the Worker; further processing according to the Customer's GTM configuration	Server-side tagging according to the Customer's configuration	Google Cloud, the region the Customer chooses	Not stored by the Operator; Cloud Logging request logs: 30 days
Request rows (BigQuery)	The fields listed in section 6, without query parameters	Counting and billing, limits, detection of automated traffic, statistics	Google BigQuery, EU (multi-region)	90 days
Daily request counts	Counts per Container, day and category, no personal data	Usage figures and invoices	Operator's database, Frankfurt	Indefinitely
Add-ons that forward data (Request Enricher, Cookie Extender, Bot Filtering, Request Proxy)	Location, network, device, selected cookies, verdict, decoded path	Running the add-ons the Customer enabled	Cloudflare, as above	Not stored, apart from the verdict in the request row
Preview Mode	Tester IP filter, path filter, requests matching the filter (without an IP filter, the requests of all Visitors)	Preview of the server GTM container	Operator's database, Frankfurt; Cloudflare, global	Session up to 60 minutes; IP filter until the Customer changes or removes it
Live Logs (where available)	The data described in section 6, redacted	The Customer checking its tags	Cloudflare Durable Objects, EU jurisdiction for a Container hosted in the EU	Until the session ends, at most 60 minutes; metadata 90 days
AI assistants (where available)	The summary and filtered events of a Live Logs session, from the data described in section 6, redacted	Letting a user of the Customer read a Live Logs session through an AI assistant, on the Customer's instruction	Cloudflare (the session's Durable Object and the analyzer Worker), the Operator's application server in Frankfurt, then the assistant's provider, the Customer's recipient	Not stored by the Operator; the provider's own retention
Same Origin Transport (where available)	The browser's request with allowed cookies; the Visitor's IP address and location and the site's host and path in headers from the Customer's Worker; the site_path marker in the request row; the failed verification marker without personal data	Tagging traffic from a path on the Customer's site	The Customer's Cloudflare account, then as in the first row	As in the first and third rows; the location is not stored; failed verification marker: 1 day after the last failure it records
Same Origin Transport's built-in Google Tag Gateway (where available)	The browser's request: its address with query parameters and its body as sent, the headers listed in section 5 (the full Referer included) and allowed cookies; the Visitor's IP address and country and region code, Google's answer; the request row with the category gateway	Loading GTM and passing Google's requests from a path on the Customer's site to Google, the Customer's recipient, on the Customer's instruction	The Customer's Cloudflare account, then Cloudflare as in the first row, then Google	Not stored, apart from the request row (90 days); Live Logs as above

Annex 2: sub-processors

Entity	Service	Data	Location	Transfer basis	Documents
Cloudflare, Inc., 101 Townsend Street, San Francisco, CA 94107, USA	Workers, KV (Container configuration), Durable Objects (Live Logs sessions), custom hostnames with TLS certificates, cache, DNS	Visitor Data while a request is handled; the Preview Mode IP filter; Live Logs data	Global network; Live Logs sessions of a Container hosted in the EU in the EU jurisdiction	EU-US Data Privacy Framework and Standard Contractual Clauses (Module 3) in Cloudflare's DPA	DPA, sub-processors, privacy policy
Google Cloud Poland sp. z o.o., Poland (the Google Cloud contracting entity for a billing address in Poland), with Google LLC and its affiliates as its sub-processors	Cloud Run (Tagging Server and preview server), BigQuery (request rows), Cloud Logging	Requests forwarded by the Worker; request rows	Cloud Run: the region the Customer chooses; BigQuery: EU (multi-region); Cloud Logging logs: 30 days	Contracting entity in the EEA; Google's onward transfers under Standard Contractual Clauses (processor to processor, Google exporter) and the EU-US Data Privacy Framework (Google LLC)	DPA, sub-processors, privacy policy
Laravel Holdings Inc., 60 Broad Street, 24th Floor, #1559, New York, NY 10004, USA	Laravel VPS (application server and MySQL database) managed through Laravel Forge	The Preview Mode IP filter, Live Logs session metadata; Live Logs data passing through, not stored, while an AI assistant or the Operator's own debugging access reads a session	Server in Frankfurt (Germany), in a data centre of DigitalOcean, LLC (USA), Laravel's sub-processor	EU-US Data Privacy Framework according to Laravel's privacy policy; Laravel Forge Data Processing Agreement	privacy policy, DPA

Annex 3: technical and organizational measures

• Encryption in transit: HTTPS connections to the Container's hosts use certificates issued through Cloudflare, with TLS 1.2 or later; the Worker connects to the Tagging Server and BigQuery over HTTPS.
• Encryption at rest: Google Cloud and Cloudflare encrypt stored data by default, according to their documentation; the Operator's database lies on the application server's local disk, which the hosting provider does not encrypt at rest, and its daily backups are stored encrypted outside that server. GTM preview tokens, Live Logs access tokens, Same Origin Transport keys and Cloudflare connection tokens are encrypted in the Operator's database, and the Worker's configuration holds only a hash of the Same Origin Transport key.
• Data minimization: request rows without bodies, cookies or query parameters (with the transition in section 6), and with the Referer header without parameters; country, region and Request Enricher data are not stored; rows are deleted daily after 90 days; Live Logs data is redacted before it is stored.
• Separation of Containers: separate Cloud Run services for each Container with a Tagging Server; a separate Worker configuration for each host; the traffic of the Container's hosts is routed through the Worker.
• Access control: in the Service, a Container's data is reached by the Organization's members and the Operator's authorized administrators, and billing is reserved to the Organization's administrators; sign-in with a password, a passkey, Google or GitHub; access to the Google Cloud, Cloudflare and Laravel Forge accounts restricted to authorized persons of the Operator; writes to BigQuery through a service account whose key is held as a Worker secret.
• Live Logs: session data can be read only with the token issued for that session; the data is deleted when the session ends.
• AI assistants: an assistant connects over OAuth 2.1 with PKCE, after its user approves that app on the Operator's consent screen; its access tokens expire after 60 minutes and stop working at once when the user disconnects the app; it reaches only what its user reaches in the Service, through the same access rules.
• Same Origin Transport: the Worker trusts headers from the Customer's Worker only when the SHA-256 hash of the Container key matches, compared in constant time, and otherwise treats the request as unverified; after a real security issue in older versions of the Customer's Worker, a minimum version with a deadline at least 30 days later, after which an older Worker's Visitor IP address and location are no longer trusted; the key is 32 random bytes and the Customer can rotate it at any time; the built-in Google Tag Gateway serves only key-verified traffic, passes only listed headers and cookies both ways and never serves Google's HTML.
• Backups and recovery: a daily backup of the Operator's database, stored encrypted outside the application server and kept for 14 days; the application and the Worker are deployed again from the code repository.
• Incident handling: the procedure in section 13.
• Sub-processors: an agreement with each sub-processor in Annex 2 covering the obligations of Article 28 GDPR.

Annex 4: transfer mechanism

The Operator is established in the EEA, so the Customer's transfer of data to the Operator is not a transfer outside the EEA. Transfers to sub-processors outside the EEA are made under the mechanisms in their agreements:

• Cloudflare, Inc. (USA): certification under the EU-US Data Privacy Framework and the European Commission's Standard Contractual Clauses, Module 3 (processor to processor), included in Cloudflare's DPA.
• Google: the contracting entity is Google Cloud Poland sp. z o.o. in the EEA; Google's transfers to Google LLC and other sub-processors outside the EEA, including for a non-EU Container region the Customer chooses, are made under Google's Standard Contractual Clauses (processor to processor, Google exporter) and Google LLC's certification under the EU-US Data Privacy Framework.
• Laravel Holdings Inc. (USA): certification under the EU-US Data Privacy Framework according to Laravel's privacy policy, and the Laravel Forge Data Processing Agreement; DigitalOcean, LLC provides the server's data centre in Frankfurt as Laravel's sub-processor.

The certification status can be checked on the Data Privacy Framework list. The Standard Contractual Clauses are part of the sub-processors' agreements available at the links above; the Operator does not attach their text to this DPA.

For data-protection enquiries contact BEO Technology sp. z o.o. at [email protected].