活动互斥策略 · PRD

作者 Luke　版本 v1.11　日期 2026-09-14　状态 进行中　平台 BRAND_A & BRAND_B　类 K

L0 · 快速掌握

① 一句话需求

在「活动管理 ＞ 活动互斥策略」配置互斥活动组。玩家通过手动领取或自动派发取得组内任一活动奖金后，策略1阻挡同组其他活动；策略2在同一主周期凭证内连同本活动的再次领取也阻挡。

② 术语写死表

③ 全局红线表

④ 范围

本期做

1. 互斥策略的新增、编辑、查询、启用、关闭、删除与导出（§1）。
2. 手动领取与自动派发前的互斥判定（§2）。
3. 策略1按用户全局互斥；策略2按单次凭证互斥（§2.4–2.5）。
4. 平台渠道前置校验、AID 过滤与编辑态完整清单操作（§1.1–1.3）。

明确不做

1. 不改活动达标、算奖与入账规则（§2.1）。
2. 不新增活动主数据或批量导入（§1）。
3. 不新增玩家端页面，也不隐藏组内活动的领取按钮（§2.1）。
4. 策略1再次领取锁定活动时，互斥层放行并交由既有幂等规则处理；策略2同凭证重复领取本活动仍由本需求阻挡（§2.4–2.5）。
5. 不替自动派发脚本定义排程；只规定脚本处理到某用户时的互斥结果（§2.2）。
6. 客服补发与后台人工补发不纳入本期（§2.1）。

1. 配置与编辑

1.1 表单字段

1.1.1　校验时机：只有「平台渠道」显示红色星号。未选平台渠道时点「添加」立即硬阻断；其余字段在提交时硬阻断。

1.1.2　并发编辑：两个运营同时编辑同一条策略时，后保存者覆盖先保存者，不做冲突提示。

1.2 AID 添加与过滤

1.2.1　过滤规则：点「添加」后，系统逐一查询输入框里的 AID，并将有效结果写入明细表。

1.2.2　策略2前提：策略2另需满足「相同 template_id 且相同主周期」。添加时检查，提交时由后端再校验；策略1不做此限制。

1.3 新增与编辑操作

1.3.1　完整清单：「添加」不是只追加单笔。每次点击都以输入框当下的完整 AID 清单为准，校验后重建明细。点击后输入框保留已通过校验的完整清单，不自动清空。

1.3.2　编辑字段：平台渠道与策略方案在编辑态锁定。策略名称、互斥周期、AID 清单可修改。备注每次操作重新填写，不带入上次内容。

1.4 列表、状态与时间

列表栏位：ID｜策略名称｜活动ID｜策略方案｜用户渠道｜状态｜到期日｜创建时间｜修改时间｜操作人｜操作｜查看

明细栏位：序号｜活动ID｜模板名称｜活动名称｜用户渠道｜活动状态｜开始时间｜结束时间

1.4.1　到期日：到期日覆盖含生效当日在内的 N 个自然日。计算式为「生效日期 ＋（N − 1）个日历日」的 23:59:59；不得以生效时刻直接加 N × 24 小时。

1.4.2　创建时间：只在首次新增成功时写入。编辑、启用、关闭、删除与自动到期均不得改写创建时间；这些操作只更新修改时间。启用或修改有效期时，另以该次操作成功时刻作为到期日的计算起点，不得借用或覆写创建时间栏位。

1.4.3　释放口径：策略关闭、删除或到期后，下一次判定立即不再命中。

2. 互斥判定

2.1 生效入口

2.1.1　判定入口：下列入口必须在入账前调用同一套互斥判定：

1. 玩家点击领取。
2. 自动派奖脚本处理该用户。

2.1.2　不判入口：活动达标、活动列表与详情展示不做判定。自动脚本不得因不是玩家点击而绕过互斥。

2.2 手动与自动的先后规则

2.2.1　自动顺序：自动 vs 自动不另设「AID 较小者优先」规则。执行先后以脚本实际处理并成功提交的顺序为准。

2.3 命中策略

2.3.1　命中条件：一条策略同时满足下列条件才参与判定：

1. 活动集包含本次 AID。
2. 策略 BRAND 等于用户 BRAND。
3. 策略未关闭、未软删。
4. 当前时间在策略生效窗口内。

2.3.2　空集合：该活动未配置任何策略，或所有策略均不满足条件时，互斥判定放行。

2.3.3　重叠策略：允许同一活动出现在多条策略。每条命中策略分别判定，任一条拦截即整体拦截；共享活动不会自动把多条策略合成一个大组。

2.4 策略1 按用户全局互斥

2.4.1　锁定活动：锁定活动为该策略活动集内、符合回溯范围且 claim_at 最早的成功入账记录所对应活动。

2.4.2　同秒决胜：claim_at 同秒时，以成功事务提交顺序或唯一入账流水序号决定锁定活动，不按 AID 大小决定。

2.4.3　回溯下界：回溯下界按活动当前状态决定：进行中活动从策略生效起点查；已过期、关闭或状态读取失败的活动从该活动运行起点查。状态读取失败时记录系统运行日志。

2.5 策略2 按单次凭证互斥

2.5.1　凭证范围：策略2只看当前主周期实例，不回溯其他实例。

2.5.2　读取失败：取不到凭证实例标识时不得派发，并按系统异常处理。

2.6 判定记录

2.6.1　记录来源：手动请求与自动任务使用相同的服务端身份、活动与成功记录口径。

2.6.2　自动拒绝：自动任务命中互斥时跳过该用户并记录原因，不把这次跳过当成系统失败重试。

3. 异常与并发

系统异常不得写入永久互斥拒绝记录。自动任务因系统异常未派发时，不得误记为「已命中互斥」。

并发保护粒度：策略1为「用户＋策略」；策略2为「用户＋策略＋凭证」。判定与成功入账必须在同一事务内完成。

4. 文案、权限与留痕

4.1 玩家端文案

4.1.1　自动任务：自动派发被互斥拦截时没有玩家端即时提示；任务记录跳过原因即可。响应与任务日志不得暴露策略ID、活动集、锁定活动、到期日或回溯下界。

4.2 后台文案

4.2.1　呈现方式：后台错误均使用弹窗。

4.3 权限与日志

4.3.1　BRAND 隔离：无权 BRAND 的资料行、平台选项与导出内容全部隐藏，后端仍需二次校验。

4.3.2　日志：新增、修改、启用、关闭、删除与导出均写管理员操作日志，记录对象ID、变更前后值、操作人和备注。自动到期写操作人 system。

5. 待确认项

自动派发的先后规则已定：不按 AID 排序，以脚本实际执行并成功提交的顺序为准。

文档版本：v1.11 | 日期: 2026-09-14 | 作者: Luke | 文档状态：进行中

Campaign Mutex Strategy · PRD

Author Luke　Version v1.11 EN　Date 2026-09-14　Status In Progress　Platforms BRAND_A & BRAND_B　Category K

English translation of the Chinese PRD v1.11. The Chinese PRD is authoritative.

L0 · Quick Overview

① Requirement in One Sentence

Configure mutually exclusive campaign groups under Campaign Management > Campaign Mutex Strategy. After a player receives a reward through Manual Claim or Automatic Payout, Strategy 1 blocks other campaigns in the group; within the same Cycle Instance, Strategy 2 also blocks reclaiming the same campaign.

② Fixed Terminology

③ Global Invariants

④ Scope

In Scope

1. Create, edit, query, enable, disable, delete, and export Campaign Mutex Strategies (§1).
2. Run the mutex check before Manual Claim and Automatic Payout (§2).
3. Strategy 1 uses a player-wide mutex; Strategy 2 uses a per-Cycle-Instance mutex (§2.4–2.5).
4. Platform pre-validation, AID filtering, and complete-list editing behavior (§1.1–1.3).

Out of Scope

1. Do not change campaign eligibility, reward calculation, or crediting rules (§2.1).
2. Do not add campaign master data or bulk import (§1).
3. Do not add player-facing pages or hide claim buttons for other campaigns in the group (§2.1).
4. Under Strategy 1, reclaiming the locked campaign passes the mutex layer and remains subject to existing idempotency rules. Under Strategy 2, reclaiming the same campaign in the same Cycle Instance is blocked by this requirement (§2.4–2.5).
5. Do not define the scheduling order for automatic payout jobs; only define the mutex result when a job processes a player (§2.2).
6. Customer-service adjustments and backoffice manual adjustments are not included in this release (§2.1).

1. Configuration and Editing

1.1 Form Fields

1.1.1 Validation timing: only Platform displays a red required mark. Clicking Add without selecting a Platform is blocked immediately. Other fields are blocked on submission.

1.1.2 Concurrent editing: if two operators edit the same strategy, the later save overwrites the earlier save. No conflict warning is shown.

1.2 Adding and Filtering AIDs

1.2.1 Filtering rule: after the operator clicks Add, the system queries every AID in the input and writes valid results into the detail table.

1.2.2 Strategy 2 prerequisite: campaigns must have the same template_id and the same primary cycle. Validate when adding, and validate again on the server when submitting. Strategy 1 does not use this restriction.

1.3 Create and Edit Operations

1.3.1 Complete list: Add does not append only one item. Every click treats the current input as the complete AID list, validates it, and rebuilds the detail table. After validation, the input retains the complete validated list and is not cleared automatically.

1.3.2 Editable fields: Platform and Strategy Type are locked in edit mode. Strategy Name, Mutex Period, and the AID list are editable. Remarks must be entered again for each operation and are not prefilled from the previous operation.

1.4 List, Status, and Time

List columns: ID | Strategy Name | Activity ID | Strategy Type | Platform | Status | Expiry Date | Created At | Updated At | Operator | Actions | Details

Detail columns: No. | Activity ID | Template Name | Campaign Name | Platform | Campaign Status | Start Time | End Time

1.4.1 Expiry Date: an N-day Mutex Period includes the effective date. Calculate it as 23:59:59 on the effective date plus (N - 1) calendar days. Do not add N × 24 hours to the effective timestamp.

1.4.2 Created At: write this value only when the strategy is first created successfully. Edit, enable, disable, delete, and automatic expiry must not overwrite Created At; these operations update only Updated At. For enable or duration changes, use the successful operation time as the separate reference point for Expiry Date calculation; do not reuse or overwrite the Created At field.

1.4.3 Release rule: after a strategy is disabled, deleted, or expired, the next check must no longer match that strategy.

2. Mutex Evaluation

2.1 Effective Entry Points

2.1.1 Required checks: the same mutex evaluation must run before crediting at both entry points:

1. The player clicks Manual Claim.
2. An Automatic Payout job processes the player.

2.1.2 No check is performed when evaluating campaign eligibility or displaying campaign lists and details. An automatic job must not bypass the mutex rule merely because it was not triggered by a player click.

2.2 Ordering Between Manual Claim and Automatic Payout

2.2.1 Automatic order: do not add an “smaller AID wins” rule. Order is determined by the job that actually executes and commits successfully first.

2.3 Matching a Strategy

2.3.1 A strategy participates in evaluation only when every condition below is true:

1. Its campaign set contains the current AID.
2. Its BRAND equals the player's BRAND.
3. It is not disabled or soft-deleted.
4. The current time is within its effective window.

2.3.2 Empty set: allow the payout when the campaign has no configured strategy or when no configured strategy satisfies all matching conditions.

2.3.3 Overlapping strategies: the same campaign may appear in multiple strategies. Evaluate every matched strategy independently. If any one blocks, block the entire payout. A shared campaign does not merge multiple strategies into a larger group.

2.4 Strategy 1: Player-wide Mutex

2.4.1 Locked campaign: within the strategy's campaign set and lookback scope, the locked campaign is the campaign associated with the earliest successfully credited record by claim_at.

2.4.2 Same-second tie-breaker: if claim_at is identical to the second, use successful transaction commit order or the unique credit transaction sequence. Do not use AID order.

2.4.3 Lookback lower bound: for an active campaign, start from the strategy effective time. For an expired or disabled campaign, or when campaign status cannot be read, start from that campaign's runtime start. Log a system event when campaign status cannot be read.

2.5 Strategy 2: Per-Cycle-Instance Mutex

2.5.1 Cycle Instance scope: Strategy 2 evaluates only the current primary-cycle instance and does not look back into other instances.

2.5.2 Read failure: if the Cycle Instance identifier cannot be obtained, do not pay out and handle it as a system error.

2.6 Evaluation Records

2.6.1 Record source: Manual Claim and Automatic Payout use the same server-side identity, campaign, and successful-record definitions.

2.6.2 Automatic rejection: when a mutex match occurs, the automatic job skips the player and records the reason. Do not treat the skip as a system failure that should be retried.

3. Errors and Concurrency

A system error must not create a permanent mutex rejection record. If an automatic job does not pay out because of a system error, it must not be recorded as a mutex match.

Concurrency lock scope: Strategy 1 uses player + strategy; Strategy 2 uses player + strategy + Cycle Instance. Evaluation and successful crediting must complete in the same transaction.

4. Copy, Permissions, and Audit Logs

4.1 Player-facing Copy

4.1.1 Automatic Payout: a mutex block during Automatic Payout does not display an immediate player-facing message. The job records only the skip reason. Responses and job logs must not expose the strategy ID, campaign set, locked campaign, Expiry Date, or lookback lower bound.

4.2 Backoffice Copy

4.2.1 Presentation: all backoffice errors use modal dialogs.

4.3 Permissions and Logs

4.3.1 BRAND isolation: rows, Platform options, and export data for unauthorized BRANDs are hidden. The server must validate permission again.

4.3.2 Logs: create, edit, enable, disable, delete, and export actions write an Admin Action Log entry containing object ID, values before and after the change, operator, and Remarks. Automatic expiry records the operator as system.

5. Open Questions

The Automatic Payout ordering rule is final: do not sort by AID. Follow actual job execution and successful commit order.

Document version: v1.11 EN | Date: 2026-09-14 | Author: Luke | Status: In Progress