Current State
The "API item views" nav link (/events/view_api) exists and renders for every hub and contributor, but shows no data. The backend classes are fully stubbed:
app/lib/api_events.rb — response returns nil, multi_page_response returns []
app/lib/api_overview.rb — same
- Comment in both: "API usage data is not tracked in GA4 — no data available."
The nav link, the events controller path, and the _timeline_api.html.erb template all exist but are dead ends.
Background
The original dashboard pulled API item view data from Universal Analytics (UA). When UA was shut down in July 2023, api.dp.la lost its data source along with everything else. During the GA4 migration, the API classes were stubbed rather than migrated, because api.dp.la does not appear to have GA4 tracking.
The ECS task definition for api.dp.la (if it still uses the old UA tracking ID UA-28197764-10) has never been updated to GA4, which means there is currently no event stream to pull from.
Investigation Needed
-
Does api.dp.la have any GA4 tracking? Check whether api.dp.la has a GA4 measurement ID configured, and if so, what events are being sent.
-
Can GA4 tracking be added to the API? The DPLA API returns JSON responses, not web pages — there are no page views. Tracking meaningful usage (queries per hub, item lookups) would require GA4 Measurement Protocol server-side events. Evaluate feasibility and what events would be actionable.
-
What per-hub attribution is possible? API calls include api_key in the query string. There is an existing mapping of API keys to hubs. In principle, per-hub API usage could be reconstructed from API logs (if retained) or tracked prospectively via Measurement Protocol with a hub dimension.
-
Fallback — remove from nav: If GA4 tracking cannot be restored in a reasonable timeframe, the correct action is to remove /events/view_api from the navigation (app/views/shared/_data_menu.html.erb, render_view_api_link) and deprecate the ApiEvents and ApiOverview classes. A dead nav link that always shows blank data is worse UX than no nav link.
Proposed Resolution
- If API tracking can be added: scope a Measurement Protocol implementation and re-enable the classes.
- If not: remove the nav item, the stubbed classes, and the unused template in a cleanup PR.
Either way, the current state (nav link present, data always blank, no explanation to the user) should not persist.
/cc @megannp4
Current State
The "API item views" nav link (
/events/view_api) exists and renders for every hub and contributor, but shows no data. The backend classes are fully stubbed:app/lib/api_events.rb—responsereturnsnil,multi_page_responsereturns[]app/lib/api_overview.rb— sameThe nav link, the events controller path, and the
_timeline_api.html.erbtemplate all exist but are dead ends.Background
The original dashboard pulled API item view data from Universal Analytics (UA). When UA was shut down in July 2023, api.dp.la lost its data source along with everything else. During the GA4 migration, the API classes were stubbed rather than migrated, because api.dp.la does not appear to have GA4 tracking.
The ECS task definition for api.dp.la (if it still uses the old UA tracking ID
UA-28197764-10) has never been updated to GA4, which means there is currently no event stream to pull from.Investigation Needed
Does api.dp.la have any GA4 tracking? Check whether api.dp.la has a GA4 measurement ID configured, and if so, what events are being sent.
Can GA4 tracking be added to the API? The DPLA API returns JSON responses, not web pages — there are no page views. Tracking meaningful usage (queries per hub, item lookups) would require GA4 Measurement Protocol server-side events. Evaluate feasibility and what events would be actionable.
What per-hub attribution is possible? API calls include
api_keyin the query string. There is an existing mapping of API keys to hubs. In principle, per-hub API usage could be reconstructed from API logs (if retained) or tracked prospectively via Measurement Protocol with a hub dimension.Fallback — remove from nav: If GA4 tracking cannot be restored in a reasonable timeframe, the correct action is to remove
/events/view_apifrom the navigation (app/views/shared/_data_menu.html.erb,render_view_api_link) and deprecate theApiEventsandApiOverviewclasses. A dead nav link that always shows blank data is worse UX than no nav link.Proposed Resolution
Either way, the current state (nav link present, data always blank, no explanation to the user) should not persist.
/cc @megannp4