Analytics

DropAFinder collects aggregated event data from your embedded widgets so you can see what visitors do with them. This page covers what’s tracked, what isn’t, where to read the data, and the privacy posture.

The visitor-facing widget posts events to POST /analytics on every meaningful interaction. The current event types:

Widget loaded — fires once per page load when the widget renders successfully
Search performed — fires when a visitor submits a search (typed an address, pressed enter or selected a suggestion)
Filter applied — fires when a visitor toggles a refinement
Location clicked — fires when a visitor clicks a location card or marker
Map interaction — fires on pan, zoom, and other map gestures (sampled, not every event)

🔴 [NEEDS CLARIFICATION: Confirm the exact event_type enum and the schema of event_data JSON per event type. The above is the most likely shape based on src/lib/analytics.js, but the field-level structure should be enumerated authoritatively before publishing.]

Each event carries a small JSON payload with context (e.g., the search query for a search performed event, the location id for a location clicked event). Events are batched and sent asynchronously; visitors don’t wait for analytics to render anything.

DropAFinder is intentionally limited in what it collects:

No personal identifiers. No name, email, account id, or login state — the widget runs in a logged-out context and has no notion of who the visitor is.
No cross-site tracking. Events are scoped to one Finder; there’s no profile that follows a visitor between Finders or between sites.
No third-party tracking pixels. The widget doesn’t load Google Analytics, Facebook Pixel, or anything similar.
No session recordings. No Hotjar / FullStory equivalent.
No keystroke logging. The widget reports the submitted search, not what the visitor typed and erased.

🔴 [NEEDS CLARIFICATION: Exact IP storage policy on the analytics table. The model has a user_ip column; whether full IPs are stored, truncated for GDPR, or not stored at all needs to be confirmed before publishing this page.]

Where to read the data

In the dashboard, open any Finder and look for the Analytics tab (or section, depending on layout). The view shows aggregated metrics for that Finder over a time window.

The default window is 30 days. You can change it via a date-range control on the page.

🟡 [SCREENSHOT: Finder Analytics view showing the 30-day window with the event-count summary at the top, a search-query word cloud, and a list of the most-clicked locations.]

🔴 [NEEDS CLARIFICATION: Confirm exact dimensions / aggregations exposed in the dashboard analytics view (e.g., total visits, unique-ish visitors, top searches, top clicked locations, click-through rate). Backend exposes GET /finders/{id}/analytics?days=N; the response shape is the source of truth.]

What you can do with it

Common uses:

Discover what visitors search for — surface popular search terms to inform which locations to add or which Custom Fields to expose
Find dead locations — Locations that never get clicked may be miscategorized or geocoded wrong
A/B compare Finders — duplicate a Finder, change one thing (theme, layout, refinement set), measure click rate
Know if visitors are using filters — if a refinement you added has zero applies, it’s probably mis-positioned or unclear

There is no export to CSV or BI-tool integration today. The dashboard view is read-only.

🔴 [NEEDS CLARIFICATION: Is there an export-to-CSV / API endpoint for analytics data that customers can use? GET /finders/:id/analytics exists but is currently consumed only by the dashboard.]

Preview mode disables analytics

When you view a Finder inside the dashboard’s Live Preview (the right rail of the Finder Builder), the widget runs in preview mode. In preview mode, analytics events are not sent. This is intentional — your edit-time interactions shouldn’t pollute your production metrics.

This means:

Editing a Finder does not show up as visits in your Analytics tab
A search you perform in Live Preview does not appear in the search-term list
Click-through tests in Live Preview do not affect the click counts

If you want to test analytics for real, you have to embed on a real (or local-dev) page outside the dashboard. The dashboard is intentionally invisible to your metrics.

For more on what preview mode does internally, see Preview mode.

Privacy posture

DropAFinder’s analytics are designed to give you product insight about your Finder’s effectiveness, not to profile visitors. Practical consequences:

The data you see is aggregated counts and lists, not individual visitor sessions
Visitor consent for analytics is your responsibility on the host page (you’re the data controller; DropAFinder is a processor on your behalf)
If you have a cookie banner or consent-management tool on your host page, the widget should be loaded conditionally based on the visitor’s analytics preference

💡 Tip: If your host page’s privacy policy mentions DropAFinder, document what you’re collecting (search queries, click events, aggregated counts) and what you’re not (no IP profiling, no cross-site tracking).

🔴 [NEEDS CLARIFICATION: Confirm whether DropAFinder offers a “do not track” or consent-aware mode that the widget honors automatically. If not, document the workaround (don’t render the widget if the visitor declined analytics).]

Edge cases and limitations

Ad blockers can suppress events. Some ad blockers and privacy extensions block requests to third-party domains. A visitor with such a blocker installed loads and uses the widget normally, but their interactions don’t show up in your analytics. There’s no fix for this on the widget side; treat reported counts as a lower bound.
The 5-minute CDN cache means very recent visitors may not appear immediately. Counts in the dashboard are eventually consistent.
Bot traffic isn’t filtered. If your host page receives bot traffic that loads the widget, those loads count. There’s no built-in bot detection.
Multiple finders on one page count separately. Each Finder’s analytics are scoped to that Finder; if you have two Finders on the same page, each gets its own load count.

Where to next

The “your changes aren’t appearing” companion: Caching
Why dashboard interactions don’t show up in your numbers: Preview mode
The full embed setup: Embedding guide
Account-level billing and tier information: Billing