Scenario Notification Content Builder
Component Detail
Description
Service responsible for generating localised, personalised notification copy for each scenario type. Injects user-specific context values (days inactive, session count, days until expiry) into message templates. Supports Norwegian and English localisation.
scenario-notification-content-builder
Summaries
The Scenario Notification Content Builder ensures every user-facing notification feels personal and relevant, directly increasing the likelihood of re-engagement. By injecting real user context — days inactive, session counts, expiry timelines — into pre-approved message templates, the business avoids generic, low-impact alerts that users ignore or dismiss. Supporting both Norwegian and English localisation means the product can serve its full user base without separate content teams managing language variants. Personalised, timely communication is a proven driver of retention and lifetime value, making this component a direct contributor to revenue and churn reduction goals.
This backend service component has medium complexity and no external dependencies, making it a relatively self-contained deliverable suitable for early-sprint implementation. The primary scheduling consideration is coordinating template content approval with product and copywriting stakeholders before code is complete — content delays are the most likely blocker, not engineering. The localisation requirement (Norwegian and English) adds a content-management workload that should be scoped separately from the code deliverable. Testing must cover all scenario types across both locales and validate that each context variable (inactive days, session count, expiry) is correctly injected.
Integration testing against the trigger engine should be sequenced after unit tests pass.
This service component exposes four interfaces: `buildNotificationContent()`, `getDeepLinkRoute()`, `getSupportedScenarioTypes()`, and `getTemplateForScenario()`. It operates in the backend execution context with zero declared dependencies, meaning all templates are resolved internally — likely via a static map or configuration file keyed on scenario type and locale. The core logic pattern is template interpolation: given a scenario type and a context data object, the service selects the matching template string and performs string replacement for placeholders such as `{{daysInactive}}` or `{{sessionCount}}`. Locale handling should follow a fallback chain (requested locale → default locale) to prevent null content.
As a shared component used across all notification features, changes to template schema or supported locales have wide blast radius and require coordinated updates across all callers.
Responsibilities
- Select the correct message template for the given scenario type
- Inject personalised context data into template placeholders
- Return localised title and body strings for both push and in-app rendering
- Generate the appropriate deep-link URL for each scenario
Interfaces
buildNotificationContent(scenarioType, contextData, locale)
getDeepLinkRoute(scenarioType, contextData)
getSupportedScenarioTypes()
getTemplateForScenario(scenarioType, locale)