A practical foundation for GDPR-compliant analytics
MOJAQ combines cookieless website measurement, service-data hosting in Helsinki and an included DPA. Your team still controls purpose, notice, access and the rest of compliance.
EU-hosted in Helsinki · GDPR-native · DPA included · free during the private beta
GDPR analytics implementation checklist
| Requirement | How MOJAQ helps | What your team still decides |
|---|---|---|
| Data minimisation | Cookieless pageviews and custom events | Which events and properties are necessary |
| Processing location | Service data hosted in Helsinki | Whether other site tools transfer data |
| Processor terms | DPA included | Controller details and internal approval |
| Transparency | A simpler analytics purpose to describe | Privacy-notice wording and publication |
| Access control | One account and dashboard | Who receives access and how it is reviewed |
| Lawful basis | Privacy-first technical design | Your legal assessment for the actual use |
| Ongoing review | One suite for analytics and developer signals | Retention, audits and change management |
No analytics product can complete GDPR for you
The phrase GDPR-compliant analytics is useful search language but an incomplete technical claim. Compliance belongs to a particular organisation, purpose and configuration. A tool can reduce collection, keep processing in a chosen region and provide contractual terms; it cannot choose your lawful basis, write an accurate privacy notice, or decide whether every custom event is necessary.
MOJAQ provides the parts a product team should expect from a privacy-first processor: cookieless web analytics, service-data hosting in Helsinki and a GDPR DPA included. Treat those as a foundation. Your record should still state why measurement is needed, which events are collected, who can access the dashboard and how analytics fits with the other scripts and processors on the site.
Start with purpose, then design the event
A defensible analytics plan begins with questions rather than every available field. If the team needs to know which documentation pages help users reach registration, page paths and a small conversion event may be enough. Sending form contents, account identifiers or arbitrary URL parameters merely because the tracker accepts custom data works against minimisation and creates review work later.
Create a short event dictionary with the event name, decision it supports, properties allowed and owner. Review dynamic URLs before launch so email addresses, order references or search terms do not leak through path or query data. MOJAQ's cookieless approach avoids analytics cookies, but data discipline still determines whether custom events remain appropriately narrow.
EU residency should cover the adjacent tools
Analytics is rarely the only developer signal on a site. Error payloads, logs and real-user performance can reveal more about a person or request than a pageview. MOJAQ hosts its suite in Helsinki, so teams can add error tracking, uptime, log search or beta Core Web Vitals without constructing a different data-residency explanation for every dashboard.
That common boundary is also operationally useful. A traffic change can be examined beside deployment, error and uptime context. One account and one API key reduce vendor sprawl, while the DPA describes the processing relationship. Access still needs an owner: remove users who change roles, avoid shared credentials and revisit event collection when the product changes.
Cookieless does not mean invisible processing
Removing analytics cookies can simplify the implementation and reduce persistent browser state. It does not mean the analytics activity should disappear from your privacy documentation. Visitors deserve a clear description of what you measure and why, and teams should not present a technical design choice as a blanket legal exemption.
Likewise, Helsinki hosting is a concrete residency property, not a guarantee that the rest of your website stays in the EU. Review embeds, form processors, support widgets, advertising tags and hosting logs as part of the same data map. The strongest setup is one whose public explanation matches what the browser and backend actually do.
A privacy-first analytics rollout
Write the purpose and minimal event dictionary before adding the script. Review page paths and custom properties for personal or sensitive values, then install MOJAQ on a test environment and confirm only the intended events arrive. Complete the DPA and update your processor inventory and privacy notice with the actual configuration. Give dashboard access only to the people who need it, record the launch date, and schedule a review after the first product changes rather than treating compliance as a one-time checkbox.
Questions
Does using MOJAQ automatically make my analytics GDPR-compliant?
No. MOJAQ supplies cookieless analytics, Helsinki hosting and an included DPA, but your organisation remains responsible for purpose, lawful basis, transparency, data minimisation, access and its wider site setup.
Do cookieless analytics need to appear in a privacy notice?
A transparent notice should describe analytics processing even when it does not set analytics cookies. The exact wording and legal assessment depend on your organisation and implementation.
Where is MOJAQ analytics data hosted?
MOJAQ hosts service data in Helsinki, Finland. The same EU-hosting model covers the other MOJAQ developer tools you choose to use.
What should a custom analytics event contain?
Only properties needed for a defined decision. Avoid form contents, secrets, direct identifiers and personal values embedded in URLs. Keep a small event dictionary with a purpose and owner.
Build analytics around a clear privacy story
Use cookieless measurement, Helsinki hosting and an included DPA as the technical foundation for your own compliant setup.
Request beta access →