Legitimate Interest Assessment - Product Analytics via APL

Template for Vevee Customers operating analytics processing under GDPR Art. 6(1)(f) - legitimate interest. Fill in your specifics, sign off internally, and keep the completed document on file for inspection by the supervisory authority. Recommended review cadence: annually.

Download as Markdown (.md) · Data Processing Agreement · Sub-processors

Not legal advice. The structure below is a working starting point; tailor each section to your concrete processing and have a qualified DPO or counsel sign off.

Header

• Controller: [Your Company Name]
• Processor: Vevee S.r.l. (“APL”)
• Processing activity: Product analytics via APL Analytics surface in the default hybrid mode.
• Date of assessment: [DATE]
• Next review: [DATE + 12 months]
• Signed off by: [Role / Name]

1. Purpose Test

What is the purpose of the processing? Analyse usage patterns of our product to identify usability issues, measure feature adoption, and optimise the user experience.

Is the purpose specific and clearly defined? Yes.

Is the purpose lawful? Yes - product improvement is a recognised legitimate business interest under Recital 47 GDPR.

Could the purpose be achieved without this processing? No. Manual user feedback alone is insufficient at scale; behavioural analytics is necessary to detect patterns invisible to individual reports.

2. Necessity Test

Is the processing necessary to achieve the purpose? Yes.

Could the same outcome be achieved with less-invasive means? Yes, in part: by running APL in hybrid mode (default), pre-login visitors are not individually tracked - only aggregate metrics are collected for unauthenticated traffic. For authenticated users, only events directly relevant to product analytics are captured; no sensitive inferences are made.

Is data minimisation applied? Yes:

• Only events directly relevant to product usage are collected.
• No fingerprinting, no cross-site tracking, no localStorage identifier in hybrid mode.
• No special category data (Art. 9) is collected or inferred.
• IP addresses are not stored: only country-level geolocation (ISO 3166-1 alpha-2) and a coarse device class (mobile/desktop/tablet) derived from headers are retained for anonymous events. The raw IP is hashed with a per-app daily salt that rotates every 24h, then discarded.

3. Balancing Test

Whose rights and freedoms are affected? Our end-users (the data subjects).

Reasonable expectations. Yes - product analytics is standard practice for SaaS applications and is disclosed in our privacy policy.

Impact on data subjects. Low. The processing does not result in decisions with significant effects, does not affect access to services, and does not influence pricing or treatment. The user experience is identical whether or not they are in the analytics dataset.

Vulnerability of data subjects. [Answer based on your user base.]

Safeguards in place.

• Right to object via in-app toggle propagating to vevee.analytics.optOut().
• Right to deletion via vevee.analytics.deletePerson() with worker-backed cascading erasure (target 7 days, max 30).
• Right of access via vevee.analytics.exportPerson() (24h signed download URL).
• Transparent privacy policy disclosure (see privacy-policy templates).
• Pseudonymisation: only our internal user id is shared with APL - no email, name, or other directly identifying data unless explicitly set via $set profile properties (under our control).
• Encryption in transit (TLS 1.3) and at rest.
• Limited retention (24 months rolling for identified events; 12 months for anonymous events).
• DPA in place with APL covering Art. 28 obligations.

Conclusion of balancing test. The legitimate interest in product improvement is not overridden by the rights and freedoms of data subjects, given the safeguards in place and the low-impact nature of the processing.

4. Outcome

• [ ] Processing under legitimate interest is appropriate. Proceed.
• [ ] Switch to a different legal basis.
• [ ] Do not proceed with this processing.

Signed: ____________________________

Role: ____________________________

Date: ____________________________

Signup guard (disposable email and repeat-device screening)

Use this section instead of the analytics one if you use vevee.guard to screen signups. The legal basis is GDPR Art. 6(1)(f) for the email and device comparison, plus an ePrivacy Art. 5(3) analysis for the device identifier. Full template: LIA_SIGNUP_GUARD.md.

Not legal advice. The ePrivacy position below is defensible but not settled law.

Purpose. Preventing free-tier farming and signups with disposable or undeliverable emails. Guard data is used for abuse prevention at signup only; Vevee never reads it for analytics, funnels, attribution, profiles, marketing exports, the Insights API or MCP.

Necessity and minimisation.

• Email (normalised), network prefix (/24 for IPv4, /48 for IPv6) and device characteristics are stored only as HMAC-SHA256 hashes keyed with a random per-app secret. No raw email, raw IP, raw user agent or raw fingerprint value is stored.
• The raw IP reaches Vevee in the request body only, is used in memory and is never stored or logged.
• No cross-app matching: an app only matches against its own signups.
• DNS over HTTPS (Cloudflare) and RDAP (rdap.org) receive only the email domain, never the address.
• Device signals read in the browser: a canvas rendering hash, the WebGL vendor and renderer, an audio context hash, an installed-fonts mask, screen and hardware characteristics, the timezone, the language and the random localStorage id vv_g; on the server the JA4 TLS digest and a reduced user agent class. All are stored only as keyed hashes.
• Matched accounts are returned as a count, never as ids or emails.
• The email domain is stored only when it is public: disposable email services, known throwaway mail servers, relay services and large consumer providers. Private and company domains are never stored; the dashboard shows them as “Private domain”.
• The dashboard shows no emails, no private domains and no matched account ids, and offers no export of the flagged or blocked lists.

ePrivacy Art. 5(3) and EDPB Guidelines 2/2023. collectDevice() reads browser characteristics and stores a random identifier in localStorage (key vv_g). Under EDPB Guidelines 2/2023 that is access to terminal equipment, so it needs consent unless it is strictly necessary for the service the user asked for. The position here is that abuse screening at signup is a security measure for that service. It is not settled: if you do not want to rely on it, collect consent before calling collectDevice(), or skip the device step (email signals work alone). State your choice in the assessment.

Balancing. Impact is low to moderate: the output is advice (allow, review, deny_free, block) that you apply, observe mode enforces nothing, and false positives come from shared networks and devices. Describe your appeal path and whether any automated refusal needs human review (Art. 22).

Retention, erasure and export. Rows expire 180 days after creation. deletePerson deletes the person's guard rows by default. With keepGuard: true (implied by keepMetering) each row loses its end user id, replaced by a random value linked to no person, and its hashes are kept until the original expiry, never extended. The stored public domain is erased with the person and is cleared on rows kept with keepGuard. Export and erasure cover the canonical id and every alias id, and the export contains hashes plus the public domain when one was stored.

Failure behaviour. The guard methods never throw. If Vevee is unreachable, the SDK option guardUnavailable decides. Past your guard allowance the check runs degraded (lists, burner mail servers, blocklist and repeated emails still checked; live DNS and RDAP domain age lookups and device matching skipped). Metering is never affected.

Notes

• This LIA covers the analytics surface only. The metering surface (track / reserve /commit) processes usage counters under performance of contract(Art. 6(1)(b)), not legitimate interest, so it doesn't require an LIA.
• If you enable the anonymous→identified merge in hybrid mode, or switch to identified mode, that processing rests on consent(Art. 6(1)(a)) - not legitimate interest - and is out of this LIA's scope. You will need a cookie banner and the consent records APL writes to consent_audit_log automatically.