Privacy Friendly Analytics Checklist: 20 Checks Before Launch

Use this checklist before you switch on analytics, and again once a year. It has 20 checks in five groups: choice, paperwork, consent, setup and review. If you can tick everything, your measurement is easy to explain to a customer, a colleague or a regulator.

General information, not legal advice. Check your regulator’s guidance and take advice for your situation.

A. Choosing the tool

1. Write down your questions. Which five decisions will analytics inform? Choose from privacy-friendly analytics tools against those questions, not against a feature list.
2. Check price against your traffic. Convert pageview, event or hit limits to your monthly numbers. See the caps in free privacy-friendly analytics.
3. Confirm hosting needs. Do you need self-hosting, or is a hosted service fine?
4. Check export. Can you get your data out in a usable format?
5. Read stated limits. For BusinessMCP, its web analytics page lists what it is not a fit for, including self-hosting and GA4-style explorations. Look for the same honesty from any vendor.

B. Paperwork

6. Get the DPA. Read it, do not just file it.
7. Read the sub-processor list and how changes are announced.
8. Note hosting region and retention. Raw events, aggregates and logs may have different periods.
9. Record the lawful basis and your reasoning in a dated page.
10. Update the privacy notice in plain language.

C. Consent

Check	Test
11. Analytics script stores nothing unexpected	Developer tools in a clean private window
12. Other scripts audited	List ad pixels, replay, embeds and chat
13. Consent states respected	Decline, reload, confirm gated scripts stay quiet
14. Banner (if any) is fair	Reject as easy as accept

Key takeaway: consent is decided per script, not per site. One forgotten pixel can undo a careful analytics choice.

For depth, see analytics without a cookie banner and, if Google tags remain, Google Consent Mode v2 explained.

D. Setup and testing

15. One tag per page. Search templates and tag managers for duplicates.
16. Verify events arrive. Follow the sequence in the install guide.
17. Name and test goals. Fire each goal once and check it records.
18. Tag campaign links with a consistent UTM scheme. BusinessMCP’s UTM guide is a decent reference.

E. Review

19. Compare with a second source for two to four weeks. Server logs or your old tool; judge direction and ranking, not exact totals.
20. Schedule a yearly review and a trigger-based review whenever scripts change.

How to score it

Ticks	Reading
18 to 20	Ready; document and move on
14 to 17	Mostly fine; close the gaps this week
Below 14	Pause launch; fix paperwork and consent first

These bands are a guide for self-assessment, not a legal standard.

Common reasons teams fail the list

Most failures come from the same few places. Teams skip the DPA because the vendor’s sign-up flow does not mention it. They test consent in a normal browser where cookies already exist from earlier visits. They add a chat widget after the audit. Or they never write down the decision, so a year later nobody knows why a setup looks the way it does. Each failure is cheap to prevent if you decide who owns analytics and when it is reviewed.

After launch

Put a calendar reminder for the review. Keep the notes next to the site’s change log. When you evaluate a replacement tool, the Google Analytics alternatives guide and the GA4 migration plan explain what to compare. For the legal reasoning behind the checks, return to GDPR-compliant web analytics.

Extra checks for specific sites

Shops. Confirm purchase events record revenue and that checkout on another domain is handled. BusinessMCP’s web analytics says it pulls revenue from Stripe, but test with a real small order whichever tool you use.

Membership or login sites. Do not send emails, account IDs or names as event properties unless you have a documented reason. Doing so creates personal data and changes your compliance picture.

Multi-country sites. Rules differ by country. BusinessMCP’s guide to website tracking laws by country is a starting overview, but your regulator’s page is the authority.

Agencies. Keep a separate record per client site, since vendors, retention and consent setups may differ.

Who should own it

Name a single owner for the analytics setup, usually the person who gets the email when something breaks. Put their name on the one-page record from section B. A checklist without an owner decays; a checklist with a named owner and a calendar reminder usually survives staff changes. The owner does not need to be technical, only able to run the tests above and ask the right questions of the vendor.

Printable summary

Keep this as a one-page record: tool name and plan; date installed; owner; DPA signed and stored where; hosting region; retention period; scripts on the site and their classification; consent decision and reasoning; goals defined; date of last review; date of next review. A page like this is the difference between a setup you can explain in two minutes and one you must reconstruct from emails. Review the page whenever a new script is proposed, and treat any script without an entry as unapproved until someone has checked what it stores and where it sends data.

When something fails a check

Failing a check is information, not disaster. If the DPA is missing, ask the vendor in writing and pause launch until it arrives. If a script sets an identifier you did not expect, find out who added it and whether it is needed. If the numbers disagree wildly with your second source, look for a missing tag or a duplicate before blaming the tool. Fix, retest, and record the date. A checklist that has been through two honest failures and fixes is far more reliable than one ticked on the first pass.