Behavioral Segmentation

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €34/mo; behavioral triggers, segment drill-down, export

Generated from docs/plan/paid/behavioral-segmentation/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Behavioral Segmentation lets merchants automatically group customers by purchase behavior, browsing patterns, and engagement level, then send targeted campaigns to each group.

The problem

Different messaging for browsers vs buyers; merchants need to segment by behavior but have no way to define or target cohorts.

What it does

• Define segments using rules (purchase count, recency, RFM)
• Trigger-based segmentation (viewed product but didn’t buy)
• Export segment lists for email/SMS campaigns
• View segment size and composition
• Drill-down to individual customers in each segment
• Re-segment on schedule (daily/weekly)
• Apply segments to email campaigns
• Historical segment membership tracking

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Email delivery (mail provider integration is email-marketing-automation-segmentation; separate paid module) — merchants export or buy email module
• ML/AI-driven auto-segmentation (requires prediction infrastructure) — rule-based only
• Cross-store behavioral rollup (each store is independent) — no account-level behavior
• Real-time segment switching (segments update on schedule) — not per-event
• Segment lookalike/lookalike audiences for ad platforms (requires data warehouse) — out of scope

Data model

Segment: id, name, rules (JSON), owner_id, created_at, updated_at, is_active. SegmentMembership: segment_id, customer_id, joined_at, removed_at. Migration: add segments table, segment_memberships join table.

API

• POST /admin/segments
• GET /admin/segments
• GET /admin/segments/{id}
• PATCH /admin/segments/{id}
• DELETE /admin/segments/{id}
• GET /admin/segments/{id}/members
• POST /admin/segments/evaluate
• GET /admin/customers/{id}/segments

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Segment builder UI with rule composer (purchase count, date range, category, RFM). Member drill-down: click segment to see customers. Recalculation history: timestamps, member delta, error log. Export: CSV of segment members.

The seam — why this is paid

Core owns: customer database, purchase history, product/category structure, rule evaluation engine. Paid module owns: segment UI/UX, rule templating, export infrastructure, recalculation scheduler.

Support commitment: segment definition validation, trigger SLA, export accuracy

Dependencies

• customer-profiles

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Creating segment with rule ‘purchase_count >= 2, last_purchase_days < 90’ returns only customers matching both
• Exporting 500-member segment downloads CSV with customer_id, email, last_purchase_date
• Updating segment rules triggers recalculation; old members not matching are removed
• Segment membership includes removed_at (removed members tracked)
• Deleting segment leaves membership records but segment_id becomes unreferenceable
• Running export 10 times concurrently does not corrupt CSV

Risks

Rule evaluation slow on 100k+ customers without indexes. Recalculation locks customer table. Exporting > 1M members crashes memory. Rule bugs cause wrong message to wrong segment. No historical removal tracking.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.