Core Analytics Intro
This file explains the main things we track for the Adapt Action Explorer and how to read them. The live product instrumentation lives in the cdp-adapt-ex frontend. The PostHog reporting scripts, meeting notes, and operating docs live here in cdp-index/projects/adapt-action-explorer.
Use these links when checking the current setup:
- PostHog dashboard: user-type tracking and demand signals
- Insight: user type selections
- Insight: user type activity by event
- Merged PR #36: Track welcome modal user roles in PostHog
- Merged PR #38: Track dashboard export and section events
- Production frontend deploy run for export and section analytics
What We Are Trying To Learn
The analytics setup is meant to answer four practical questions:
| Question | What we look at |
|---|---|
| Who is using the Explorer? | The selected user_type, captured from the welcome role choice and attached to later events. |
| Are people finding relevant places? | Search selections, map pin clicks, and location page views. |
| Are people exploring adaptation evidence? | Section engagement, hazard expansion, hazard-to-action clicks, action opens, solution opens, and AI chat usage. |
| Are people trying to preserve or reuse the data? | Export and data-link events such as export_clicked and export_completed. |
Core Events
| Event | What it means |
|---|---|
$pageview | A page was viewed. The app sends this manually so it can include the stored user_type. |
user_role_selected | A visitor chose a role in the welcome flow. This sets the user_type for later reporting. |
search_location_selected | A visitor selected a jurisdiction from search or a search result path. |
map_pin_selected | A visitor selected a location directly from the map. |
location_viewed | A full location profile loaded. This is one of the best signals that someone reached useful content. |
location_tab_changed | Legacy section movement event. The dashboard still uses to_tab as a fallback for historical data. |
section_engaged | Current section movement event. Use the section property for hazards, actions, solutions, and related section-level reporting. |
hazard_detail_expanded | A visitor expanded hazard detail content. |
hazard_actions_explore_clicked | A visitor moved from a hazard into related adaptation actions. |
action_hazard_filter_applied | A visitor filtered actions by a hazard. |
government_action_opened | A visitor opened a disclosed government action. |
funding_project_opened | A visitor opened a project seeking funding. |
adaptation_goal_opened | A visitor opened an adaptation goal. |
solution_detail_opened | A visitor opened a solution example. |
ai_chat_opened | A visitor opened Ask CDP AI. |
ai_chat_query_submitted | A visitor submitted a chat query. Query text should be treated carefully because it may include user-entered content. |
ai_chat_followup_clicked | A visitor clicked a suggested AI follow-up question. |
export_clicked | A visitor clicked an existing data/export-style link. This is a demand signal for data reuse, not proof that a file was downloaded. |
export_completed | The app handed the visitor to an external data destination. Today this means completion_type = external_link_opened. |
export_failed | Reserved event contract for failed export handoffs. It should only appear when a failure path exists or is observed. |
Common Properties
These properties make the dashboard useful:
| Property | Use |
|---|---|
user_type | Breaks behavior down by audience type, such as government, business, funder, civil_society, researcher, or general. |
role | The role selected during user_role_selected. |
previous_role | The previous role when a visitor changes role. |
source | Where the action came from, such as the welcome modal, hazard-to-actions flow, or an open data portal link. |
location_id / location_name | Ties behavior to a jurisdiction. |
from_tab / to_tab | Legacy section transition fields. |
previous_section / section | Current section engagement fields. |
hazard_type | Connects hazard exploration and action filtering to climate risk types. |
action_count / matching_action_count | Shows whether the hazard-to-action path led to available actions. |
export_type | Distinguishes all-data links, location open-data links, and raw dataset links. |
destination_url | External destination opened by the export/data-link click. |
export_delivery | Current value is external_portal; this is a handoff, not an in-app generated download. |
Export Tracking Interpretation
The export events do not mean that new export buttons were added to the product. They instrument links that already existed:
- Footer
Download all data. - Hazards page links to the CDP Open Data Portal.
- No-data or limited-data location banners that point visitors to open data.
- Methodology page raw dataset links.
Read export_clicked as “someone showed intent to take data out of the Explorer.” Read export_completed as “the browser was handed to the external data destination.” It does not prove the external site loaded successfully or that the visitor downloaded a file after leaving the Explorer.
Dashboard Views
The main dashboard is PostHog dashboard 750470. The highest-signal views are:
| View | What it answers |
|---|---|
| User type selections | Which audience types are identifying themselves. |
| User type activity by event | Whether each audience type is searching, viewing locations, opening actions, using AI, and clicking export/data links. |
| Section engagement | Which location sections people move through, using section_engaged.section with location_tab_changed.to_tab as the legacy fallback. |
| Export events | Which existing data/export links are being clicked and by which user type. |
| Health and errors | Whether broken paths, exceptions, or rage-click style signals are undermining the usage story. |
What This Cannot Prove
The current analytics can show product demand and path quality. They cannot prove:
- Whether a user implemented an adaptation action after visiting the Explorer.
- Whether an exported external dataset was downloaded after the user left the Explorer.
- Whether a visitor’s selected role matches their real-world organization.
- Whether high engagement is strong without comparing it to other CDP dashboards or interactive pages.
Follow-Up Questions
Use these questions when deciding what to track next:
- Which role breakdowns matter most for stakeholder reporting: government, funder, business, researcher, civil society, or general public?
- Should stakeholder-facing reports include preview traffic, or should they only use production traffic?
- Is external data-link intent enough, or do we need true in-app export/download events?
- Which next actions matter most: print, copy, PDF, save, share, or outbound funding links?
- What CDP dashboard or page should be used as the benchmark for “strong” engagement?
Verification
PostHog project 141282 is on https://eu.posthog.com. Use the local scripts from this folder when checking current data:
doppler run --project cdp-worldwide --config dev -- npm run posthog:fetch -- --days 7 --limit 10For a custom HogQL query, pass --query through the same script:
doppler run --project cdp-worldwide --config dev -- npm run posthog:fetch -- --days 7 --limit 10 --query "SELECT event, count() AS events FROM events WHERE timestamp >= now() - INTERVAL {days} DAY GROUP BY event ORDER BY events DESC LIMIT 20"