Analytics Integrations API

The native analytics layer in BricksMembers turns semantic BRM events into provider-safe analytics dispatches for AnalyticsWP and Independent Analytics, while also powering the widened BRM-owned Analytics admin page.

This runtime intentionally reuses the same event vocabulary exposed by the shared Automations trigger catalog, but it does not reuse the automations queue, workflow storage, or provider connection model.

Scope and Boundary

  • Owned by native analytics: provider dispatch registration, provider-safe payload shaping, analytics metadata layered on semantic trigger aliases, and the BRM-owned Analytics page read model
  • Owned by Automations: workflow execution, action dispatch, queueing, connections, and provider HTTP for automation actions
  • Owned by providers: third-party plugin UIs, their own storage, and their own reporting internals

Canonical Owners

  • AnalyticsFeatureRegistrar — bootstrap and page-availability owner
  • AnalyticsEventSubscriber — event subscription and provider dispatch coordination owner
  • AnalyticsContextBuilder — provider-safe context shaping owner
  • AnalyticsCatalogService — semantic catalog overlay owner on top of the automation trigger catalog
  • AnalyticsWpProvider — AnalyticsWP provider adapter
  • IndependentAnalyticsFrontendTracker — Independent Analytics provider adapter and read-side enrichment owner
  • AnalyticsInsightsReadService — BRM Analytics page read owner
  • ProgressDashboardPage — route shell for the current Analytics page at admin.php?page=brm_progress_dashboard

Bootstrap and Gating

  • BootstrapCoordinator::boot_modules() boots the analytics feature after module-owned automation trigger packs register their semantic aliases.
  • AnalyticsFeatureRegistrar::boot() stays dormant unless analyticswp or independent_analytics is enabled in ModuleRegistry.
  • AnalyticsFeatureRegistrar::is_analytics_page_available() also allows the page when progress_tracking is active, even if no analytics provider module is enabled.

Settings and Options

  • brm_enable_analyticswp
  • brm_enable_independent_analytics
  • brm_analyticswp_events
  • brm_analyticswp_conversion_events
  • brm_independent_analytics_events

These settings save through the existing general settings mutation path in SettingsFormHandler and AdminSettingsService. Do not add a second analytics-specific save owner.

Semantic Event Catalog

AnalyticsCatalogService is not a duplicate event registry. It layers analytics metadata on top of the active semantic trigger catalog exposed through AutomationTriggerRegistryService.

  • It decides whether a semantic event is supported for AnalyticsWP.
  • It decides whether a semantic event is supported for Independent Analytics.
  • It exposes provider-default enabled event sets and AnalyticsWP conversion defaults.

If a new semantic event is missing from analytics, first check whether the owning module trigger pack exposed it in the automation trigger catalog before you patch analytics-specific code.

Consumed Hooks and Filters

  • brm_event
  • user_register
  • brm_analytics_context
  • brm_analytics_should_dispatch

Provider Contracts

AnalyticsWP

AnalyticsWpProvider dispatches through \AnalyticsWP\Lib\Event::track_server_event(). It derives a stable unique_event_identifier from the BRM correlation id, semantic key, and resource id, and adds conversion metadata when the semantic key is listed in brm_analyticswp_conversion_events.

Independent Analytics

IndependentAnalyticsFrontendTracker dispatches through do_action( 'iawp_custom_form_submissions', ... ). It intentionally limits dispatch to frontend-attributable requests and ignores admin, cron, CLI, import, webhook, and other backend-only contexts.

That adapter also owns read-side enrichment through iawp_analytics() and iawp_singular_analytics() when those reporting functions are available.

Admin Surfaces

  • BricksMembers → Integrations owns module enablement and provider event-selection controls.
  • Analytics at admin.php?page=brm_progress_dashboard remains the BRM-owned reporting route, even though the label is now simply Analytics.
  • When the relevant provider pages are registered, BRM mirrors the provider links into the BRM sidebar so admins can jump into AnalyticsWP or Independent Analytics from the same navigation system.

The BRM Analytics page itself is a read surface. It does not write provider configuration, provider events, or provider-side analytics rows.

Read Path for the BRM Analytics Page

AnalyticsInsightsReadService::get_dashboard_data() aggregates:

  • provider readiness and inspection links
  • BRM-owned aggregate stats such as level grants, completions, submissions, quiz activity, video activity, and certificates
  • top content, top quizzes, and top videos
  • optional Independent Analytics sitewide and singular pageview enrichment

The canonical route owner stays ProgressDashboardPage. Do not add a second analytics page just to display the same data differently.

Provider Boundaries and Safety

  • Do not write third-party analytics plugin tables directly.
  • Do not route analytics through AutomationRuntimeService or automation jobs.
  • Do not claim that backend-only events are visitor-attributable for Independent Analytics.
  • Keep provider payloads provider-safe and filtered through AnalyticsContextBuilder.

Related

Early Bird Deal

Start Building Your Membership Site Today

Create, sell, and manage your content without limits. BricksMembers gives you everything you need to build membership and LMS sites with Bricks Builder.

Get BricksMembers

Lifetime updates & bug fixes • Premium support • 0% transaction fees • 60-day money-back guarantee