Privacy and Respectful Measurement at NAU Apps
See how NAU Apps keeps website analytics consent-aware, limits custom event data, and separates catalog measurement from app responsibilities.
NAU Apps uses website measurement only when it is configured and a visitor accepts analytics. The current implementation is designed to answer a small set of catalog questions while keeping navigation independent from tracking and avoiding personal information in custom event payloads.
This article explains the operating principles behind the website implementation. The Privacy Policy remains the source of truth for the public privacy notice.
Start with a named question
Measurement should begin with a decision the team needs to make. For the NAU Apps website, useful questions include whether visitors move from the homepage to an app detail page and whether they choose an official app-distribution destination.
Those questions do not require tracking every section, scroll, hover, or visual impression. Collecting more events can create maintenance and interpretation work without improving a product decision.
The current custom event set is intentionally small:
- app selections from named catalog placements,
- outbound app-distribution clicks,
- sanitized website page views.
New events should require a named question, an owner, and a clear reason that existing page or product data cannot answer it.
Consent comes before the Google tag loads
When Google Analytics is configured for the production website, the tag is not loaded before a visitor accepts analytics. Rejecting analytics keeps collection disabled.
The preference is stored in the browser so the site can remember the decision. Visitors can reopen analytics preferences from the footer and change that choice later.
When a visitor rejects analytics after previously accepting it, the site stops new collection, sends a denied consent update when available, and removes known Google Analytics cookies on a best-effort basis. Browser and provider behavior can vary, which is why the wording remains specific rather than absolute.
Keep event data narrow
Custom analytics helpers use typed event names and allow-listed properties. The implementation is designed to avoid sending email addresses, support-message text, full query strings, or arbitrary campaign values.
Page locations are sanitized so only approved campaign parameters can remain. Destination links are reduced to normalized domains for outbound product events rather than sending the full external URL with unrelated query data.
This approach does not mean no data can ever be processed by the website or external providers. It means the custom measurement layer is constrained around its stated catalog questions.
Navigation must work without analytics
App and catalog links remain normal links. Tracking is a best-effort side effect after consent, not a requirement for navigation.
This matters for reliability and trust. A visitor should still be able to open an app page, reach the Shopify App Store, visit a product website, or change pages when analytics is unavailable, blocked, or rejected.
Separate website and app responsibilities
The NAU Apps website, each published app, its marketplace, and external technology providers can have different responsibilities.
- NAU Apps website: catalog pages, website support paths, consent-aware website analytics, and public legal pages.
- Individual app: product behavior and app-specific data handling described through its official materials.
- Marketplace: installation, billing, marketplace terms, and current listing information.
- External providers: behavior governed by their own systems, policies, and technical controls.
The AnswerAtlas app page uses scoped trust items to make these boundaries visible. Website analytics should not be described as AnswerAtlas telemetry, and app behavior should not be inferred from catalog events.
A respectful measurement checklist
Before adding a new website event, ask:
- What decision will this event support?
- Is the event already available from existing page or product data?
- Can the property be represented without personal or free-form data?
- Does the event remain disabled before consent?
- Does navigation still work when tracking fails?
- Who will review whether the event remains useful?
- Does the Privacy Policy need to change?
The principle is simple: collect less, explain more, and keep product access independent from measurement.
Read the current NAU Apps Privacy Policy, learn what NAU Apps builds and why, or review the publisher principles on the About page.