Data processing agreement

Effective August 17, 2026 · AppGlance is made by Ludyem AS, Norway

1. Parties and scope

This agreement is between you - the person or organisation holding an AppGlance account - and Ludyem AS, a limited company registered in Norway ("we", "us"). It governs our processing of personal data relating to your end users that reaches us because you shipped the AppGlance SDK or called our ingest API.

It forms part of the terms of use and takes effect when you create an account. No signature is required. If your organisation needs a counter-signed copy on your own paper, write to [email protected].

It does not cover the personal data of you, our customer - your own name, email and billing details. For that data we are the controller, and the privacy policy explains it.

If you self-host the schema or the ingest Worker, we process nothing and this agreement is not engaged for that deployment.

2. Roles

For end-user data, you are the controller and we are the processor. You decide what your app sends, why, and on what lawful basis. We provide the pipe, the storage and the dashboard, and we do not decide the purposes of the processing.

You confirm that you have a lawful basis for everything you send, that you have told your own users what you collect, and that you will not send special-category data or data about children below the applicable age of consent. Those obligations are set out in section 7 of the terms and are not repeated here.

3. Our instructions

We process end-user data only on your documented instructions. Your instructions are:

• this agreement and the terms of use;
• your configuration of the service - the apps you register, the events your SDK sends, the retention window your plan carries, the webhooks and alerts you enable;
• any further written instruction you give us, which we may decline if it is not technically feasible or would require us to break the law.

We will tell you if, in our opinion, an instruction infringes the GDPR or other applicable data protection law.

We do not use your end-user data for our own purposes. We do not sell it, share it, use it to build advertising profiles, use it to train machine-learning models, or combine it with data from other customers to produce benchmarks or industry statistics. We access it only to run the service, and only as described in Annex 2.

If we are required by law to process end-user data beyond your instructions, we will tell you before doing so unless that law forbids it.

4. Confidentiality

Everyone we authorise to process end-user data is bound by a duty of confidentiality - by contract of employment, by a written confidentiality undertaking, or, where the person is a director or owner of Ludyem AS, by the confidentiality duties that role carries under Norwegian company law. That duty survives the end of their engagement.

AppGlance is operated by a very small team. The number of people with production access is correspondingly small, and it is kept to those who need it to run the service.

5. Security

We implement appropriate technical and organisational measures under Article 32, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing, as well as the risk to individuals. The measures in force are listed in Annex 2.

Annex 2 is a description of what we actually do, not an aspiration. We may change individual measures as the service evolves, but we will not reduce the overall level of security during your subscription.

6. Sub-processors

You give us general authorisation to engage sub-processors. The ones we use today are listed in Annex 3, with what each one does and where it does it.

Before we add or replace a sub-processor we will give you at least 30 days' notice by email to your account address, and by updating Annex 3. If you object on reasonable data protection grounds within those 30 days, tell us and we will work with you to find a solution. If we cannot, you may terminate the affected part of the service and we will refund any prepaid fees covering the period after termination. Continuing to use the service after the notice period is acceptance.

We impose data protection obligations on every sub-processor that are no less protective than those in this agreement, and we remain fully liable to you for their performance.

7. Data subject rights

Your end users are your users, not ours. We are not their point of contact, and if one of them contacts us directly we will not respond substantively - we will tell them to contact you, and forward the request to you where we can identify your account.

We help you meet your own obligations with the tools built into the product, which let you act without waiting for us:

• Access and portability - the dashboard shows everything we hold for a given install id, and the API returns it.
• Erasure - a per-user delete removes that install's events, its rollup rows and its labels; an app-wide delete removes the app and everything ever sent for it. Both are immediate and irreversible.
• Rectification and restriction - because what we hold is what your app sent, correcting it means sending corrected values or deleting the install.

If a request needs something the dashboard cannot do, we will give you reasonable assistance, taking into account the nature of the processing and the information available to us.

8. Breach notification

If we become aware of a personal data breach affecting end-user data we process for you, we will notify you without undue delay, and in any event within 48 hours of becoming aware of it, by email to your account address.

The notification will describe, as far as we know it at the time: the nature of the breach, the categories and approximate number of individuals and records affected, the likely consequences, the measures we have taken or propose to take, and a contact point. Where we cannot provide all of it at once, we will provide it in phases without undue delay.

Deciding whether the breach must be reported to a supervisory authority or to the individuals is your call as controller - we will give you the information you need to make it.

9. DPIAs and prior consultation

Taking into account the nature of the processing and the information available to us, we will give you reasonable assistance with data protection impact assessments under Article 35 and with prior consultation of a supervisory authority under Article 36. In practice, this page and the privacy policy are designed to contain most of what such an assessment needs; ask us if something is missing.

10. Deletion and return

You can delete end-user data yourself at any time, per user or per app, and deletion is immediate and irreversible.

When your account closes, we delete all end-user data we hold for you within 30 days, except where storage is required by law. You can export what you need before then, through the dashboard or the API.

Backups are a partial exception: end-user data can persist in encrypted backups after live deletion, and is removed as those backups age out, within 90 days. It is not restored to live systems in the meantime, and stays subject to this agreement until it is gone.

Separately from account closure, event history expires on its own according to the retention window your plan carries - 90 days on Free, longer on paid plans. Expired raw events are deleted automatically. Aggregate rollups that contain no event detail (daily counts, first-seen dates, per-user totals) are kept for as long as your account exists, because the charts read those rather than raw rows.

11. Audits and information

We will make available to you the information necessary to demonstrate compliance with Article 28 and to allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.

In practice, for a service at our scale, we ask you to start with this page, Annex 2, and written questions to [email protected], which we will answer within 30 days. If that genuinely does not satisfy a legal or regulatory requirement you are under, we will accommodate an on-site or remote audit: no more than once in any twelve months (unless a supervisory authority or a breach requires otherwise), on at least 30 days' written notice, during business hours, without unreasonable disruption, subject to confidentiality, and at your cost. We may exclude information whose disclosure would compromise the security of other customers.

12. International transfers

End-user events are stored in the European Union - Supabase on AWS eu-west-1, Ireland. Norway, where we are established, is in the EEA, so our own processing involves no third-country transfer.

Some sub-processors necessarily process data outside the EEA - a request hits the Cloudflare edge location nearest the device, and Stripe operates from the United States. Where that happens, the transfer relies on the European Commission's Standard Contractual Clauses, on an adequacy decision where one covers the recipient, or on another Chapter V mechanism, as recorded in each provider's own data processing terms. Annex 3 says which applies to whom.

13. Liability and precedence

The limitations and exclusions of liability in the terms of use apply to this agreement, except where GDPR Article 82 gives an individual rights that cannot be limited by contract.

If this agreement conflicts with the terms of use, this agreement wins for anything concerning the processing of end-user personal data. The terms of use govern everything else.

14. Changes

We may update this agreement to reflect changes in the service or in the law. For changes that materially reduce your rights or our obligations, we will give at least 30 days' notice by email to your account address before they take effect. Sub-processor changes follow section 6. We keep the effective date at the top of this page current.

Annex 1 - details of processing

Annex 2 - technical and organisational security measures

The measures below are in force as of the effective date at the top of this page.

Isolation between customers

• Every table holding customer or end-user data has PostgreSQL row level security enabled. There is no table without it.
• Raw event tables carry no read policy at all. Not even the account that owns the data can select from them directly. Every dashboard read goes through a function that re-derives ownership from the authenticated session and returns only rows for apps that session owns - so "not yours" and "no data" are the same answer, and there is no query shape that returns another customer's rows.
• The keys that ship inside your app binary and inside our web pages are write-scoped or inert. The publishable web key can read nothing and, since 15 August 2026, write nothing. A per-app write key can only write, and the server resolves it to an app on its own - an event claiming to belong to a different app is stored under the app the key belongs to, never the claimed one.
• Table-level privileges are revoked to match the policies, so that a mistakenly added policy cannot by itself open a path to data.
• Cross-tenant isolation is verified by testing an authenticated session that owns nothing against a real, populated app, across every read and write path, and requiring empty results and refusals from all of them.

Encryption

• In transit: HTTPS/TLS everywhere - device to ingest, browser to dashboard, and our own administrative connections to the database, which verify the server certificate chain against a pinned root.
• At rest: database storage and backups are encrypted at rest by the infrastructure providers (AWS/Supabase, Cloudflare).
• Operational database exports held outside the hosting provider are encrypted with a key that is not stored alongside them, on full-disk-encrypted hardware.
• We do not apply end-to-end encryption that would make the data unreadable to us: aggregating events into counts, charts and searchable labels is the service, and it requires the data in readable form. Access is controlled instead, as described here.

Access control

• Dashboard access requires an account, with email-and-password or a federated identity provider (Apple, Google, GitHub). Two-factor authentication is available and, once enrolled, is enforced by the database itself rather than only by the interface.
• Administrative credentials are held in a personal encrypted credential store, never in the code repository, and never transmitted anywhere but the service they belong to.
• Production access is limited to the people who need it to run the service, and is not shared.
• Application secrets are held as platform-managed secrets, separate from source code.

Data minimisation by design

• The SDK mints a random per-install identifier. It is not the advertising identifier, not tied to an Apple or Google account, not shared between apps, and cannot be used to recognise the same person in someone else's app.
• Location is a two-letter country code derived from the device's own region setting - never GPS, never inferred from IP.
• Identifying labels are optional, off by default, and require you to call identify deliberately.
• Presence heartbeats are discarded rather than stored as history, and raw events are deleted automatically at the end of your plan's retention window.

Resilience, integrity and testing

• The ingest endpoint authenticates every request, caps body size and batch size, and applies rate limits at the edge.
• Event ingestion is idempotent - a retried batch cannot double-count.
• Incoming values are length-clamped and type-checked before storage, and anything rendered in the dashboard is escaped.
• Database backups run on a schedule, and the schema is reproducible from version control.
• Changes to the database are applied as reviewed migrations, dry-run inside a transaction against production and rolled back before being applied for real.

Organisational

• Everyone with access is bound by confidentiality (section 4).
• Sub-processors are assessed before engagement and listed publicly in Annex 3.
• Security-relevant defects are treated as production incidents and fixed before feature work.
• We do not use production end-user data for development or testing.

Annex 3 - sub-processors

These are the third parties that process end-user data on our behalf. Changes follow the 30-day notice process in section 6.

We do not use any analytics, advertising, session-recording or customer-support tool that receives end-user event data.

Contact

Data protection questions, audit requests, sub-processor objections and anything else about this agreement: [email protected].

Ludyem AS, Norway. We have not appointed a data protection officer - our processing does not meet the Article 37 threshold - so the address above reaches the people responsible.