# Bloomreach Context Pack

Use this pack when generating Bloomreach Engagement segmentations, scenarios, lifecycle opportunities, or node-level content from project discovery data.

Keep this file generic. Do not store client names, workspace names, tenant IDs, credentials, session files, API tokens, customer-level PII, or project-specific consent IDs here. Put client-specific facts in the relevant project context or team context instead.

## Purpose

Bloomreach project data is most useful when it is treated as evidence for strategy, not as a pile of assets to copy. The agent should use discovered schemas, assets, and scenario patterns to recommend measurable customer value growth opportunities while respecting consent, suppression, frequency, and production safety.

## Load Order

For this lightweight generator, load context in this order:

1. Repo guidance: `AGENTS.md` and `docs/agent-context/router.md`.
2. Local context map: `contexts/overview.md`.
3. Business and industry lens: `contexts/team.md` and `contexts/industries/<industry>.md` when relevant.
4. Platform rules: this file.
5. Saved project context: `contexts/projects/<project>/project.md`, `schema.md`, `assets.md`, `events.json`, and `customer_properties.json` when relevant.
6. Supplied project evidence: `projectContext` or `projectContextJson` from Loomi MCP through Claude Code/Codex, another host agent, or a saved JSON file.
7. Optional Bloomreach CLI workspace export: `context/context-router.md`, `context/search-index.json`, selected `context/cards/**/*.md`, and selected raw fallback only when those files are available.
8. Task packet: goal, task family, loaded facts, assumptions, scope, and missing context before generation or implementation work.

When raw project context is available, use these files as exact fallback sources, not default reading material:

- `scenarios.json`
- `segmentations.json`
- `event-types.json`
- `customer-properties.json`
- `aggregates.json`
- `expressions.json`
- `consent-categories.json`
- `channel-providers.json`
- `metrics.json`
- `funnels.json`
- `event-segmentations.json`
- `weblayers.json`
- `recommendations.json`
- `integrations.json`
- `email-templates.json`
- `sms-templates.json`
- `email-blocks.json`
- `snippets.json`

Never load or persist:

- Browser storage state
- Bridge session files
- Credentials or secrets
- Raw customer records
- Email addresses, phone numbers, or other PII unless explicitly required and approved

## Strategy Context Shape

Every Bloomreach strategy task packet should include evidence for these sections when relevant.

### Business Model

Capture:

- What the business sells or provides.
- Whether the project is production, development, demo, or sandbox.
- Market, language, and region scope.
- Business units, categories, brands, or verticals.
- Whether the business is ecommerce, retail, grocery, subscription, marketplace, financial services, gaming, sportsbook, travel, or another vertical.

### Primary Goals

Tie recommendations to customer value, not campaign activity.

Common goals:

- First purchase
- First-to-second purchase
- Repeat purchase
- Revenue growth
- Margin growth
- Consent growth
- Loyalty activation
- App activation
- Churn prevention
- Reactivation
- Paid media efficiency
- Data quality
- Deliverability health

### Lifecycle Definitions

Define lifecycle thresholds before recommending segmentations.

Common lifecycle states:

- Visitor or anonymous browser
- Lead or consented subscriber
- Registered user
- First-time buyer
- Active repeat customer
- Healthy customer
- At-risk or lapsing customer
- Churned customer
- VIP or high-value customer
- Loyalty or app member

Avoid assuming universal thresholds. Purchase cadence, churn windows, and value tiers must come from business context or project evidence.

### Priority Categories And Products

Capture:

- Priority product or content categories.
- Seasonal or campaign moments.
- High-margin or strategic categories.
- Excluded or sensitive categories.
- Category affinity signals.
- Recommendation assets and catalog availability.

### Channels

List which channels are available, allowed, and actively used.

Common channels:

- Email
- SMS
- Push
- Weblayers or banners
- In-app messages
- Paid media audiences
- Webhooks
- External integrations

Do not assume a channel is approved just because a schema or consent category exists. Check active usage, provider configuration, consent policy, and business rules.

### Consent And Suppression Rules

Always use the exact consent category IDs from the current project. Do not reuse consent IDs from another workspace.

Before proposing a send scenario, verify:

- Required consent category.
- Frequency policy or recent-send suppression.
- Invalid email or phone suppression.
- Market, language, and channel eligibility.
- Staff, test user, seed, and internal account exclusion.
- Recent purchaser exclusion where relevant.
- Existing control or holdout treatment.
- Unsubscribe and tracking requirements.
- Transactional vs marketing classification.

If consent, unsubscribe, tracking, or communication type fields are absent from existing assets, flag the risk instead of copying the pattern.

### Discount And Offer Policy

Do not default to discounts. Start with relevance, timing, urgency, social proof, loyalty value, education, content, or convenience.

Use incentives when:

- The customer is high-value but at risk.
- The journey targets lapsed customers.
- The business has explicitly approved voucher or discount use.
- The campaign is clearance, promotion, or seasonal by design.
- The expected incremental value outweighs margin cost.

Avoid:

- Training customers to wait for discounts.
- Applying broad offers to low-intent audiences.
- Sending vouchers without eligibility, expiry, and suppression rules.
- Recommending offers without margin or measurement context.

### Known Use Cases

Group existing and proposed assets by business use case before recommending new work.

Common Bloomreach use cases:

- Welcome and onboarding
- Consent capture and preference capture
- First purchase activation
- First-to-second purchase
- Browse abandonment
- Cart or basket abandonment
- Checkout abandonment
- Wishlist, waitlist, back-in-stock, low-stock, or price-drop
- Post-purchase education
- Review or UGC request
- Cross-sell and next-best-product
- Replenishment or purchase cadence
- Birthday and anniversary
- Loyalty, points, voucher, referral, and app activation
- VIP retention
- Churn prevention
- Reactivation and winback
- Paid media audience sync
- Campaign, newsletter, and promotion sends
- Survey and voice-of-customer
- Data hygiene and operational alerts

### Known Issues And Do Not Touch

Capture production risk explicitly.

Common issues:

- Stale active assets.
- Test, copy, backup, or dry-run assets in production.
- Missing descriptions.
- Missing or inconsistent consent fields.
- Missing communication type or unsubscribe settings.
- Duplicated scenario families created by copying instead of parameterization.
- Large scenarios with excessive branching or webhook fanout.
- Inaccessible APIs or partial discovery.
- Current-state segmentations used incorrectly for retrospective analysis.

Common do-not-touch rules:

- Do not start, stop, archive, pause, or update production assets without explicit approval.
- Do not modify user-facing templates without review.
- Do not use test-named assets as production references unless the task is an audit.
- Do not copy high-risk or platform-flagged scenarios as-is.

## Segmentation Design Rules

Good segmentations are based on current, available signals and explain why the audience should convert.

For each recommended segment, include:

- Objective: business outcome.
- Lifecycle state: where the customer is now.
- Value or health signal: customer value, RFM, purchase count, order frequency, churn risk, engagement, category affinity, loyalty state, app state, or consent state.
- Bloomreach logic: exact events, properties, aggregates, expressions, or existing segmentations from the current project.
- Eligibility: consent, market, language, channel, suppression, and frequency.
- Personalization hooks: product, category, timing, lifecycle copy, content, offer, or recommendation asset.
- First scenario: the natural activation path.
- Measurement: KPI, control or holdout, attribution window, and guardrails.
- Risk: consent, over-contacting, stale data, low intent, margin leakage, or duplicated existing assets.

Prioritize segments that:

- Use existing events, properties, aggregates, or expressions.
- Have a clear next best action.
- Address a lifecycle gap or high-value drop-off.
- Can be measured with holdout or target/control logic.
- Improve or extend existing coverage without duplicating active assets.

Demote segments that:

- Require unavailable data.
- Depend on broad discounts by default.
- Rely on a current-state segment for retrospective analysis.
- Create sensitive or surprising personalization.
- Ignore consent, suppression, or frequency policy.
- Duplicate an existing active audience without a better angle.

## Scenario Design Rules

Good scenarios copy proven graph mechanics, not stale business logic.

For each scenario blueprint, specify:

- Trigger: event, repeated schedule, planned trigger, or immediate trigger.
- Entry event and property filters.
- Audience gates: consent, lifecycle, market, language, and customer state.
- Suppressions: recent purchase, recent send, invalid contact, staff/test, and control group.
- Branching: value tier, lifecycle state, category affinity, engagement, product availability, loyalty/app state, or consent state.
- Wait strategy: immediate, fixed wait, optimal send time, silent hours, or dynamic wait.
- Channel actions: email, SMS, push, weblayer, in-app, webhook, paid audience, set property, or add event.
- Conversion goal and measurement plan.
- Fallback behavior when data is missing.
- Governance fields: naming, description, consent category, communication type, frequency policy, unsubscribe settings, and owner.

Common scenario mechanics:

- Event-triggered response after registration, consent, cart update, checkout, purchase, product view, wishlist, survey, or loyalty action.
- Scheduled audience refresh for lifecycle, churn, paid media, or data hygiene.
- Wait-and-check pattern to prevent sending after a conversion already happened.
- Branching by market, language, category affinity, value tier, or engagement state.
- Control-group split before messaging.
- Silent-hours or optimal-send-time wait before customer-facing channels.
- Set-property or add-event actions for state tracking and reporting.
- Webhook action only when an external system needs to be updated.

Avoid:

- One giant scenario for unrelated use cases.
- Copying a whole scenario just to change a date, language, market, or product.
- Sending without rechecking eligibility after a wait.
- Sending without consent or frequency policy.
- Scenarios with no description, owner, or measurement plan.

## Measurement Rules

Every recommendation should state how it will be evaluated.

Recommended KPIs:

- Incremental revenue vs. control
- Repeat purchase rate
- First-to-second purchase conversion
- Recovered revenue
- Reactivation rate
- Retention rate
- Segment value movement
- Gross margin or margin per customer
- Consent growth
- App activation
- Paid media match rate or audience performance
- Unsubscribe, opt-out, complaint, and frequency-pressure guardrails

Prefer:

- Holdout groups for lifecycle automations.
- Target/control for promotional sends.
- Clear attribution windows by use case and channel.
- Segment-level reporting by value and lifecycle health.
- Guardrail metrics alongside revenue metrics.

## Governance Rules

Before calling a segmentation or scenario ready:

- The target use case maps to a business goal.
- Required events, properties, aggregates, and channel settings exist.
- Consent IDs are exact for the current project.
- Frequency and suppression rules are explicit.
- The proposed audience does not duplicate an existing active audience without a reason.
- The proposed scenario has a control/holdout or clear measurement plan.
- Content is personalized from available, non-sensitive data.
- Production changes require explicit approval.
- Known project risks are called out.
- The recommendation states what data was used and what remains unknown.

## Output Standards

When recommending segmentations, do not stop at names. Include logic, conversion reason, required data, risk, and first scenario.

When recommending scenarios, do not stop at trigger and email. Include gates, waits, suppressions, branches, channels, measurement, and governance fields.

For generated email scenarios in this repo, use the contentgen runtime pattern: per-customer webhook action, `webhook.available` check, `webhook.cache_key` stored in `customer.customer_variant`, cache-exists condition, and dynamic template lookup from `catalogs.aiagent`. Credentials must be referenced through project variables or approved secret storage.

When project context is incomplete, say which missing data prevents confidence and propose the smallest discovery step needed.