DataAcuity — Internal Product Analytics Framework

How DataAcuity powers product decisions across the entire TGN + Circle ecosystem

Classification: Internal Links: AppInfo/DataAcuity/DataAcuity_Full_Proposition.md — external B2B product Links: AppInfo/DataAcuity/DataAcuity_Data_Flow.md — technical pipeline Links: AppInfo/DataAcuity/Circle_Products_Integration.md — Circle family signals Links: AppInfo/SleptOn/SLEPTON_UX_ANALYTICS.md — SleptOn UX deep dive Memory: .claude-memory/unified-activity-feed.md, .claude-memory/shared-ai-capabilities.md

DataAcuity Has Two Roles

This distinction is critical and must be held clearly:

The external product has strict anonymisation and suppression rules — documented in DataAcuity_Data_Flow.md.

The internal analytics layer is different:

• Data stays inside the Bengu Group perimeter — never sold, never shared
• Can be at session/user level for authenticated interactions (POPIA-compliant internal processing)
• Powers product decisions: what to build, what to fix, what to kill
• Feeds the "pivot and grow" loop for every product in the ecosystem

We do NOT send internal analytics to third parties (no Amplitude, no Mixpanel, no Google Analytics, no Meta Pixel). We built our own. We eat our own dog food.

The Full Product Ecosystem — DataAcuity Coverage

DataAcuity must have visibility across ALL products:

The Geek Network (17 consumer apps)

SDPKT, Bruh!, txtMe!, SleptOn, TagMe, Panik, TrustSeal, The Job Center, KiffStore, ShhMoney, The Hot List, WhatWeWant, Sorted Clothing, BidBaas, CircleOS, Takemehome.co.za, Big Bruh!

External signals documented in DataAcuity_Data_Flow.md (per-app event schemas) Internal analytics: real-time usage, funnel analysis, retention, UX friction

The Circle Product Family

• Aether by Circle — mesh networking protocol + node network
• CircleOS — the operating layer for power users and developers
• CircleOne — the keyboard app (isiBheqe Unicode, custom layouts)
• CircleUp — [to be defined — see AppInfo/CircleUp/CircleUp_Product_Stub.md]

Signals documented in DataAcuity/Circle_Products_Integration.md

The SleptOn Developer Platform

SleptOn is both a consumer app AND a developer platform. The developer side (SleptOn as an app store / distribution channel) has its own signals:

• Developer portal usage (login frequency, app submission rates, API usage)
• Binary upload performance (from SleptOn.CLI — success rate, timing, file size distribution)
• Developer retention (do developers keep submitting? What causes them to stop?)

SleptOn-specific analytics documented in AppInfo/SleptOn/SLEPTON_UX_ANALYTICS.md

The Internal Analytics Architecture

Data separation

Internal analytics uses a SEPARATE pipeline from the external B2B product:

[App events] ──► [Wolverine event bus] ──► [External DataAcuity pipeline]  (anonymised, B2B)
                                      │
                                      └──► [Internal Analytics pipeline]     (session-level, owned)
                                                      │
                                              [Internal Dashboard]
                                              (Big Bruh! analytics console)

The branch point is at Wolverine ingestion. Same event bus, two consumers. Internal pipeline retains session-level detail. External pipeline anonymises first.

Internal data retention

After retention period: aggregate → anonymise → archive. Raw deleted.

Internal dashboard

Big Bruh! (the ops console) is the home for internal analytics. Real-time dashboards per product. Alert rules on KPIs. Drill-down to session replay (opt-in users only).

Dashboards needed (to be built):

• SleptOn creator funnel (registration → first publish → first sale → retained)
• SleptOn buyer funnel (discovery → view → purchase → return)
• SleptOn platform health (upload success, payment success, search quality)
• Aether mesh health (node count, delivery rate, coverage gaps)
• CircleOS developer adoption (API call rate, error rate, DAU)
• CircleOne keyboard usage (language distribution, error rate)
• Per-app DAU/MAU/WAU across all 17 TGN apps
• Cross-app journey funnel (storybook → first app download → Bruh! adoption)
• Qi/Karma distribution dashboard (is the redistribution flowing?)
• DataAcuity external revenue dashboard (B2B sales, report downloads, API calls)

The "Pivot and Grow" Loop

DataAcuity internal analytics enables a structured decision cycle:

1. MEASURE    → DataAcuity captures what's happening across all products
2. UNDERSTAND → Internal dashboard surfaces patterns, friction points, drop-offs
3. DECIDE     → Product team identifies where to pivot or double down
4. BUILD      → Code the change
5. DEPLOY     → Ship to .104/.105 (web) or stores (mobile)
6. MEASURE    → Loop back to step 1

What triggers a pivot signal

KPI Framework by Product

Universal KPIs (all products)

SleptOn-specific KPIs → see SLEPTON_UX_ANALYTICS.md

Aether-specific KPIs → see Circle_Products_Integration.md

CircleOS-specific KPIs → see Circle_Products_Integration.md

CircleOne-specific KPIs → see Circle_Products_Integration.md

Why We Don't Use Third-Party Analytics

1. POPIA compliance: Sending user data to Amplitude/Mixpanel = cross-border transfer requiring consent and regulatory notification. We don't want that complexity.

2. Mission alignment: We tell users "we pay you for your data and we don't exploit it." Sending it to a US analytics company contradicts that.

3. Cost at scale: Amplitude/Mixpanel pricing scales with events. At 17 apps × millions of events, the cost would be significant. Our own pipeline costs only storage + compute.

4. Depth: Third-party analytics can't capture Aether mesh signals, Qi/Karma flows, or cross-app journey data. Only we can.

5. B2B product integrity: The external DataAcuity product would be less credible if we were simultaneously sending data to third parties.

Implementation Priority

Phase 1 (now): Define all event schemas (being done in DataAcuity_Data_Flow.md + this session)

Phase 2: Build internal ingestion pipeline (branch from Wolverine, store in TimescaleDB)

Phase 3: Build Big Bruh! analytics dashboards (per-product, real-time)

Phase 4: Build external DataAcuity Pro API (connect to anonymised cohort layer)

Phase 5: Build Industry Report generation pipeline

Phase 6: Expose CircleUp developer analytics portal (developers see their own app's signals)