Reviews
Part of How to think about dental marketing analytics
Keeping dental performance numbers honest starts with minimal data and clear limits
dental marketing analytics best practices use minimal data, stable definitions, tested events, operational checks, clear caveats, decisions, and deletion.
Begin with the choice the practice needs to make
Weak version: The practice gathers whatever a platform offers before stating a decision. With no question, options, owner, or decision date, staff cannot explain why a field exists or which purpose justifies keeping it. Later users inherit data fields without knowing whether they still support current work.
Better version: Write down the question, available options, responsible person, and decision date first. Approve only information and purposes needed to make that choice; leave out everything else. Record where each field goes, who can use it, how long it remains, how it will be checked, and which decision it supports. Include privacy risk in the review, and connect decision-led planning to that stated purpose.
Make the counting rules repeatable
Weak version: A metric label is assumed to explain itself. Without a formula, scope, version, owner, trigger, parameters, exclusions, and test cases, separate reports can use the same name while counting different things. The polished chart then hides uncertainty in its definition.
Better version: Keep a metric dictionary and an event specification with explicit definitions. The practice example defines new patient exam bookings as completed appointments of that type across all locations, excluding internal training. It also identifies an owner and version. For a form event, record its trigger, parameters, and exclusions so another person can test whether it reflects the intended action.
| Record | Definition from the practice example |
|---|---|
| Metric name | New patient exam bookings |
| Formula | Count of appointments with type new patient exam and status completed |
| Scope | All locations, excluding internal training |
| Owner and version | Marketing operations lead; version 1.1 |
| Event name | form_submit |
| Trigger and parameters | User clicks Request appointment and the form passes validation; form_id, location_id, consent_status |
| Exclusion | Submissions from office IP addresses |
Keep definitions clear enough for another reviewer to apply the same scope and exclusions. The record should identify its owner and current version, while the form trigger should state its validation condition and parameters. In this example, excluding office IP submissions prevents those entries from being included in the event count.
Put the limits beside each reported result
Weak version: A reported number is presented as a full account of patient activity, and attribution appears certain. The figure may leave out consent and product conditions, unmatched phone or offline activity, and operational classifications that are sampled or incomplete. Readers can mistake recorded events for the whole journey.
Better version: State the boundaries beside each number. Explain that browser events depend on consent and product conditions, phone and offline activity may not match, attribution follows the selected model, and operational classifications may be sampled or incomplete. Restrict raw records to people with a defined need and the least access their role requires. This also supports claim evidence questions.
Turn each safeguard into an observable task
Weak version: A policy lists access controls, checks, and correction duties without naming the person responsible for doing them. Changes to access, source defects, and disputed conclusions can then pass without a trace. A safeguard written down but never exercised has not been shown to work in reporting.
Better version: Give every control an owner, cadence, input, output, acceptance test, and correction route. Observe it during a routine report and a controlled failure, then record the monitoring review date and conditions that would prompt an earlier check. Keep the original decision and its rationale visible through campaign governance, rather than retaining only the final report.
Explain changes that interrupt the series
Weak version: A gap or shift appears in the numbers with no record of releases, imports, access changes, or corrections.
Product history may explain some account activity, but it may not capture code, tags, vendors, dashboards, or operational changes. Without a trail, reviewers cannot readily relate a change to a break.
Better version: Record the version, approver, and release note for each change, then compare those entries with changes in the reporting series. GA4 change history records specified account and property changes for two years, including time, location, item type, action, and the responsible user. Keep a launch approval checklist with the related records.
- Use individual accounts and inspect tags and imports before a release.
- Annotate releases and campaign changes, and keep incident and correction records.
- Remove access for departed staff and vendors; test recovery and administrative ownership.
- Review data-quality indicators for missing, modeled, sampled, or delayed data.
Logging retains records of access, changes, failures, and corrections; it does not prove that a metric is valid. For each correction, retain its reason, scope, owner, and impact so another reviewer can follow the adjustment. Keep the original choice and its rationale available alongside the record, using strategy decision questions where useful.
Give stored data a defined end point
Weak version: Data remains because storage is inexpensive, while responsibility for deletion and exports is unclear. A product setting cannot account for copies in dashboards, agency systems, call systems, forms, backups, or archives. Without a named owner and method, a written retention period may never lead to deletion.
Better version: Specify the retention period, owner, deletion method, and review date, then check product settings alongside exports and connected systems. State the approved method, including shredding the file where that method is selected. Keep raw records more restricted than aggregated decision reports so exported files do not become ungoverned shadow systems.
Retention Lifecycle
- Set retention period
- Record owner and deletion method
- Restrict raw data
- Prevent shadow exports
- Review backups and archives
- Delete on schedule
Better version, continued: The practice example sets event data retention at 14 months and aggregated reports at 26 months, with the marketing operations lead responsible. It deletes raw exports within 30 days of reporting close by shredding the file and expiring the shared link. Check exports, vendors, backups, and deletion rather than assuming a product control reaches every copy.
A written business associate agreement with each vendor is one of the HIPAA marketing basics for exports and call systems. Keep retention no longer than the approved purpose and applicable duties allow. For applicable security responsibilities, consult the HHS Security Rule materials, and confirm export and deletion controls across vendors and other systems.
At each quality review, record the decision, action, owner, and due date. Test deletion and export controls before leaving a vendor, and set the next review date. Keeping these details together makes the period, deletion method, ownership, and follow-up checkable rather than leaving a written limit without an operational test.
