PushHub Customer Workspace

Purpose

The customer workspace is the authenticated product surface at https://app.pushhub.kemegames.com/dashboard. Gaming studios and digital publishers use it to connect apps, register player devices, define audiences, compose notifications, automate sends, inspect delivery, and manage organization access.

The workspace is tenant-isolated and dark-only. Interactive controls use SIGNAL brand-500; signal-400 remains reserved for AI-specific features.

Workspace access now begins through the approved trial provisioning path documented in docs/TRIAL_APPROVAL_FLOW.md: marketing request, Keme Admin approval, email CTA, password setup, then first workspace login. Direct public registration redirects to the trial request path in the production UI.

Competitive baseline

The July 2026 workspace expansion was informed by official product documentation from:

• OneSignal: application setup, users and segments, campaigns, journeys, templates, message reports, engagement trends, audience activity, and data export.
  • https://documentation.onesignal.com/docs/en/quickstart-guide
  • https://documentation.onesignal.com/docs/en/analytics-overview
  • https://documentation.onesignal.com/docs/en/journeys-analytics
  • https://documentation.onesignal.com/docs/en/exporting-data
• Firebase Cloud Messaging: notification composition, segment targeting, custom payloads, test sends, A/B testing, delivery reporting, and BigQuery export.
  • https://firebase.google.com/docs/cloud-messaging
  • https://firebase.google.com/docs/cloud-messaging/send/firebase-console
  • https://firebase.google.com/docs/cloud-messaging/understand-delivery
• Airship: project-per-app organization, message and automation composers, message-level reports, payload inspection, activity history, delivery reasons, and aggregate engagement reports.
  • https://www.airship.com/docs/guides/getting-started/basics/
  • https://www.airship.com/docs/guides/messaging/reports/message/
  • https://www.airship.com/docs/guides/reports/reports/
• Pushwoosh: app and account reporting, message history, campaign and journey performance, custom dashboards, exports, segment insights, device growth, and channel breakdowns.
  • https://docs.pushwoosh.com/product/statistics-and-analytics/statistics-faq

The resulting PushHub baseline is app-scoped operations plus organization-wide access, billing, auditability, and credentials. Cross-channel email/SMS/in-app messaging is intentionally outside the current push-focused domain model.

Information architecture

Workspace

• Command center — real delivery metrics, recent campaigns, setup checklist, and plan usage.
• Apps — create, inspect, configure, and remove game applications.

Audience

• Players & devices — paginated registered device inventory with platform and activity state.
• Segments — reusable filter definitions with server-evaluated audience estimates.

Messaging

• Campaigns — lifecycle views for drafts, scheduled sends, running sends, completed sends, and cancellations.
• Campaign composer — content, template application, custom JSON payload, all/segment/device targeting, A/B variants, review, send-now, and scheduling.
• Automations — event-triggered notification rules with templates, delay, activation, update, and deletion.
• Templates — reusable notification content.
• Experiments — A/B campaign visibility and results.

Insights

• Analytics — recorded-only delivery funnel, 7/30/90-day time series, quality rates, campaign context, and CSV export.
• Delivery logs — event-level status, recipient, platform, timestamps, failure diagnostics, filters, pagination, and CSV export.

Developer

• Launch checklist — recorded provider, device, and accepted-push evidence for every active app.
• App setup — FCM/APNs diagnostics, protected credential updates, active-device selection, real test push, and delivery-policy controls.
• API credentials — one-time secret display, hashed storage, scopes, last use, and revocation.

Organization

• Team & roles — owner, admin, developer, and analyst access.
• Audit trail — actor, action, resource, origin, filtering, pagination, and export.
• Billing & usage — apps, devices, monthly notifications, team limits, plan, and renewal state.
• Workspace settings — organization name/logo and related operational links.

Backend additions and contract repairs

• GET /api/v1/campaigns/{id} returns campaign detail.
• GET /api/v1/notifications/logs returns tenant-filtered, app-scoped paginated delivery events.
• App analytics now return app identity, active device count, gap-filled daily time series, and real delivery/open/failure values.
• PUT /api/v1/event-triggers/{id} updates trigger configuration and activation.
• DELETE /api/v1/event-triggers/{id} deletes a trigger.
• Campaign status filtering is enforced.
• Frontend contracts now match backend query/body requirements for campaigns, templates, members, billing usage, and event triggers.
• App and API-key controllers now resolve the authenticated company_id claim emitted by the JWT service; registration consumes the current login-response contract.
• Workspace JWTs emit company_role in addition to standard role claims so owner/admin permission checks work consistently.
• Login-time company membership lookup bypasses tenant query filters because authentication happens before a workspace JWT establishes tenant context.
• Unauthorized workspace responses redirect to /login.
• Workspace operations expose tenant-scoped readiness, provider health, exact audience estimates, seven-day delivery diagnostics, test delivery, and delivery-policy management under /api/v1/workspace.
• Campaign send-now now remains draft until a worker atomically claims it; scheduled campaigns are dispatched by the scheduler at their UTC instant instead of being queued early.
• App delivery policies enforce overnight quiet hours in an explicit IANA time zone and an exact rolling 24-hour per-device cap. Policy-denied events are retained as Suppressed logs with an actionable reason.

All delivery-log queries retain the existing EF Core company filter. App, campaign, and event-trigger reads also resolve through tenant-filtered repositories.

Data integrity decisions

• No workspace screen fabricates activity, rates, audience size, platform distribution, or hourly behavior.
• Empty workspaces show setup guidance and explicit empty states.
• Audience estimates are evaluated by the segment service after creation.
• Campaign detail uses recorded notification logs for sent, delivered, opened, failed, delivery rate, and open rate.
• API and provider secrets are never read back after storage.
• Audience estimates use the same active app devices and persisted segment memberships used by delivery; the composer never invents an audience count.
• Frequency-cap reservations are atomic in Redis. A provider failure releases its reservation, while policy-storage failure suppresses delivery rather than bypassing customer safeguards.

Responsive behavior

• Desktop uses a persistent 272 px navigation rail.
• Tablet and mobile use an accessible overlay navigation drawer.
• Data tables retain horizontal scrolling where column density is operationally important.
• Page actions collapse and wrap without hiding critical controls.

Verification

• Frontend: npm run build
• API: dotnet build PushHub.API/PushHub.API.csproj -c Release
• Production smoke coverage should verify login, apps, campaigns, analytics, delivery logs, members, audit logs, API keys, billing, readiness, app health, audience estimates, diagnostics, and service health after deployment.
• scripts/verify-workspace.sh performs authenticated production checks with a short-lived token generated from protected server configuration. Its only POST is the non-mutating All audience estimate; it never sends a notification, changes data, or prints the secret or token.
• PushHub.PhaseTwoChecks verifies quiet-hour boundaries and DST behavior, validation, suppression state, credential diagnostics, Redis concurrency, reservation release, tenant isolation, and rolling-window pruning.

The legacy test project was moved to .NET 9 with current dependencies, but its older fixtures still use superseded domain constructors. That test-fixture migration is separate from the workspace implementation; the deployable API and frontend projects compile successfully.

Security maintenance

• AutoMapper was upgraded from vulnerable 13.0.1 to patched 15.1.1 for CVE-2026-32933.
• IdentityModel packages were aligned to 8.14.0.
• API credentials remain one-time-view secrets.
• Provider credentials remain write-only in the customer UI.