Local search analytics becomes unreliable when a profile action, website session, call, form, and booked job are placed in one funnel without a location identity or serviceability check. A step-by-step audit should show what is observed, how it is joined, which owner acts, and what remains too immature to call value.
1. Define the audit question
Write whether the audit supports a market launch, budget decision, profile repair, local page review, response-capacity check, or attribution correction. State location, service, language, date range, owner, and stop rule.
Do not begin by asking for “all local metrics”. Choose the decision first; otherwise the audit becomes a dashboard inventory with no correction path. The audit should be small enough to repeat after a page, profile, form, or routing change.
2. Establish location identity
List stable location ID, profile, page, phone, address or service area, service, hours, language, CRM queue, owner, and status. Record source, permission, effective date, expiry, and reviewer for local facts.
Check duplicate, closed, moved, unverified, or unsupported locations. A report can be numerically complete while combining two locations or assigning a service-area request to the nearest profile.
Keep a location registry with stable ID, profile URL, page URL, phone, service area, owner, status, and last verification. Closed, paused, and no-data locations must not collapse into one zero.
3. Review profile signals
Use Business Profile performance guidance to define what verified profiles can report about discovery and actions. Keep views, clicks, calls, messages, website actions, direction requests, and bookings separate.
Record profile, date range, device, query or action, change log, and access owner. Profile interaction is an exposure or interest signal; it is not proof that the business could serve the person.
4. Check search and website visibility
Use the Search Console Performance report to label organic observations by page, query, country, device, and date. Keep impressions and clicks separate from Analytics sessions, calls, forms, and CRM stages.
Inspect page, canonical, redirect, local proof, language, service area, CTA, and form. A local page can gain visibility while sending visitors to a generic or unserviceable route.
Review local claims, testimonials, hours, service area, language, proof, currency, and response promise at the same time as query and page data.
5. Audit events and source scope
Use GA4 event guidance to define page, CTA, form, call, booking, validation, submit, and confirmation events. Add location, service, language, placement, form version, and consent state where appropriate.
Keep user, session, event, campaign, profile, CRM, and sales scopes distinct. A source or location inferred from an IP, phone, or nearest branch should be labeled unresolved until the join is verified.
6. Reconcile the handoff
Draw profile or search → page → event → form or call → record → local queue → response → accepted stage → delivery. Test valid, duplicate, timeout, wrong location, missing notification, consent refusal, and manual fallback.
Sample records by location and disposition. Record ID, owner, timestamp, source, service, response, acceptance, rejection reason, and mature stage. A completed browser event with no record is an exception, not a conversion.
Preserve the sample with browser path, event name, response, server status, record ID, owner notification, and final disposition so the audit can locate the failing layer.
7. Inspect capacity and lag
Record service hours, staff, inventory, language, SLA, queue age, response time, booking lag, delivery lag, cancellation, and payment. Split cohorts when offer, page, form, owner, service area, or profile changes.
Label recent data immature and keep a known-unknowns column for consent-limited, direct, duplicate, late, or manually corrected records. Do not replace a delayed outcome with zero. Preserve cohort cutoff and change points for form, offer, owner, profile, service area, and CRM stage.
8. Use the audit board
| Layer | Evidence | Hold if | | — | — | — | | identity | location ID, page, profile, owner | duplicate or unresolved location | | visibility | profile, search, page observations | source or date missing | | interaction | event, call, form, booking | event is called booked work | | source | campaign, profile, page, scope | location is inferred silently | | handoff | record, queue, owner, SLA | lead is orphaned | | value | accepted, delivered, paid | cohort is immature | | capacity | hours, service, queue | more demand cannot be answered | | governance | update, privacy, retirement | no steward exists |
Choose PASS, REPAIR, NARROW, PILOT, or HOLD. Link each finding to a sample and correction owner. Keep the evidence sample attached to the decision so a new analyst can reproduce the conclusion. Preserve the cutoff and owner with it. The audit then remains comparable after handoff. Keep the access and source notes in the same package. That record lets an operations owner verify whether a reporting correction changed the public path, the CRM handoff, or only the dashboard. Keep the evidence dated and versioned. This prevents later confusion. After handoff, too.
Set a review cutoff and stop rule before changing budget or page scope. Unresolved location identity or serviceability should hold expansion.
9. Close with one decision
Archive source exports, access evidence, public samples, event specification, CRM sample, profile state, change log, and rollback. End with one accountable action, due date, evidence target, and stop rule. Write the decision in one sentence that distinguishes fact, interpretation, missing evidence, and next test.
Local search analytics is useful when it protects a location decision from optimistic ambiguity. The audit should explain what was visible, what was requested, what could be served, and which mature outcome is actually evidenced.
How did this article land?
Choose one reaction. You can change it anytime.
