chore:文档补全
This commit is contained in:
Evilom
@@ -0,0 +1,233 @@
|
||||
# HXwUd6Wyjo1xHwxV4v9cjpNvnKe
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/docx/HXwUd6Wyjo1xHwxV4v9cjpNvnKe
|
||||
|
||||
|
||||
# 一、工作内容概述
|
||||
# **二、珍珠采集与护身符系统研究结论**
|
||||
## **背景：首发版本会议中关于采集珍珠系统的讨论**
|
||||
|
||||
> [嵌入电子表格: QvCbsE4rqhH0VRtNIc6c...]
|
||||
|
||||
三种方案在结果上趋同，都会产生**筛选**行为。区别在于筛选的驱动力是"恶心感"还是"利益感"。对官方而言，原护身符的产出控制可能更稳定，因为互惠符会推高整体产出且不可控
|
||||
**最终会议倾向：****按原规则推进**
|
||||
**理由：****改动收益、社交影响和数值影响都缺少验证，不应在缺证据时直接改造**
|
||||
|
||||
|
||||
|
||||
## **会后研究核心判断**
|
||||
**珍珠采集 + 护身符是花园经营品类的标配基础设施，不是《我的花园世界》的差异化设计。** 早在《鲜花小镇》时期就已有"抓花农 + 盾牌阻挡 + 被挡者获金币"的完整组合，《秘密花园HD》同样存在高度同构规则
|
||||
|
||||
## **基于官方概率公示的收益分析**
|
||||
官网"六、采集珍珠相关公示"确认：
|
||||
- 雇佣成功率 90%（系统自然失败率 10%，护身符是在此之上的额外阻挡）
|
||||
- 珍珠数量分布：200 颗概率最高（47%），期望值约 215 颗/次
|
||||
- 1 雇佣书 = 1 次雇佣，1 宝箱 = 100 珍珠
|
||||
**每日免费产出推算：**
|
||||
- 每日 2 次免费雇佣 → 约 1.8 次成功 → 约 387 珍珠 → **约 3.8 个宝箱/日**（无阻挡）
|
||||
- 若好友池中约 30% 开启护身符 → 实际约 **2.7 箱/日**
|
||||
- 差距约 1 箱/天
|
||||
**每箱产出结构：**
|
||||
- 约 71% 概率出单个培育材料/土壤（28 种全覆盖但每次只有 1 个）
|
||||
- 约 12% 中档资源（元宝 10/金币 5000/水滴·加速·花坊币各 10）
|
||||
- 约 12% 高价值（大量材料 ×15、元宝 188/88、金币 80000）
|
||||
- 约 5% 经验
|
||||
**关键结论：被阻挡 1 次的实际经济损失极小（约 1-2 个培育材料），但心理框架是"50% 每日免费配额被另一个人作废了"。** **经济影响和心理影响严重不对称**
|
||||
## **护身符在品类中长期存在的假设**
|
||||
**花园经营日常循环是纯 PVE，珍珠采集/抓花农是****让玩家每天必须面对具体好友头像、做出选择、并产生区分认知的系统**
|
||||
**护身符的存在让"点好友"不退化为纯挂机：**
|
||||
- 有成功/失败的不确定性
|
||||
- 失败有可归因对象（不是"概率不好"，是"那个人挡了我"）
|
||||
- 产生"谁好用、谁不好用"的区分认知
|
||||
**护身符结构的特殊性：被雇佣方无损失却可阻挡。** 这在偷菜/Coin Master 等经典"攻防"设计中不存在（那些是保护自己资源）。**花园品类选择让"阻挡"变成一个****无自利动机的社交信号****——****"不使用护身符"成为零成本的友好表达，任何玩家都能做到**
|
||||
|
||||
|
||||
**"雇佣采珍珠"在公会竞赛任务池中占 7.38%**
|
||||
珍珠采集不只是独立材料补充系统，已接入组织目标。公会竞赛期间被护身符阻挡的"感知损失"更大——损失的不仅是个人材料，还可能是对公会的贡献进度。这可能是护身符引发社交筛选的真正放大器
|
||||
## **结论**
|
||||
品类标配 + 无法明确指标提升 + 最坏只是边缘摩擦 → **首版按原规则上**，埋数据点，定义改动触发条件。不应占据首版核心设计辩论时间。** 公会竞赛节奏、商业化释放时序、压力曲线才是真正影响成败的设计层**
|
||||
# **三、复刻项目"策划觉得该改"的判断方法论**
|
||||
从珍珠采集争议中抽象出的通用判断流程，适用于所有复刻项目中的设计分歧
|
||||
## **核心原则**
|
||||
**复刻项目的默认姿态应是"先原样跑通，有数据后再改"，而不是"觉得不好就先改"**
|
||||
**原因**：
|
||||
|
||||
> :writing_hand:
|
||||
## **判断流程**
|
||||
策划直觉"这里不好"
|
||||
│
|
||||
├→ 1. 品类标配 vs 目标产品独创？
|
||||
│ ├→ 品类标配 → 证据门槛高（需数据反对经过多产品验证的设计）
|
||||
│ └→ 目标产品独创 → 证据门槛中等（只有一款产品验证过）
|
||||
│
|
||||
├→ 2. 改了后能预期哪个指标提升？
|
||||
│ ├→ 能明确（如留存、付费率、好友添加率）→ 可设计 A/B test
|
||||
│ └→ 不能明确（只是"感觉好点"）→ 优先级降低
|
||||
│
|
||||
├→ 3. 不改的最坏后果是什么？
|
||||
│ ├→ 可能损害核心留存/付费 → 值得优先验证
|
||||
│ └→ 边缘体验摩擦 → 排到有数据时再说
|
||||
│
|
||||
└→ 4. 执行建议
|
||||
├→ 首版按原规则上
|
||||
├→ 埋好数据追踪点（被阻挡后删好友率、7日留存、系统日活跃占比等）
|
||||
└→ 定义改动触发条件（"如果指标 X > 阈值 Y，则启动 A/B test"）
|
||||
## **"原版不改"是什么级别的证据？**
|
||||
"不改"可能意味着：
|
||||
- 他们有数据证明它正向 → 不该改
|
||||
- 影响太小不值得排期 → 可改可不改
|
||||
- 改动风险高于收益（线上经济牵连）→ 不是因为好，是因为改不动
|
||||
- 品类惯性，所有竞品都这样 → 没人验证过替代方案
|
||||
**多款品类产品长期保留同一结构，至少证明它"不致命"。但"不致命"不等于"好"**
|
||||
策划不适感的正确用法：**作为调查触发信号，不是改动依据**
|
||||
# **四、发行测试流程优化讨论**
|
||||
**聚焦测试周期长、跨部门协同低效问题，推动建立可复用的标准化工作流**
|
||||
## 测试流程现状与痛点
|
||||
### 测试周期长（关键瓶颈）
|
||||
- 当前测试周期约20天，从对接到上线耗时过长
|
||||
- 包体准备复杂：**无测试包体储备**，线上项目如GOS需协调梦加及厦门项目，大碰撞欧美包需重新打包、测试、上架
|
||||
- 商品页定制耗时：为不同美术风格配套定制商店页，拉长物料筹备周期
|
||||
### 必须依赖线上项目包体（刚性约束）
|
||||
- 仅测点击率可投落地页，评估转化成本必须有通过审核的应用商店及可安装包体
|
||||
- 转化成本评估需拥有完整测试链路：**广告 **> **应用商店 **>** 下载转化**，无法跳过
|
||||
### 缺乏系统性支持（组织问题）
|
||||
- 当前测试链路中各流程高度依赖项目组临时发起，且主要靠项目组推动全流程，无系统性支持
|
||||
- 发行、商务、资质、财务等职能未形成协同机制
|
||||
- 未来如需进行国内测试，前置工作更多更复杂，如软著申请、小程序备案、账户开设等前置准备工作需耗时长达1-2个月
|
||||
- 流程零散、跨部门无协同，导致人力与沟通成本浪费
|
||||
## 国内与海外测试差异
|
||||
### 海外测试：**模式成熟、渠道单一、相对简单**
|
||||
- 可临时调用已有线上包体进行测试，流程顺畅
|
||||
- 新建应用商店通过审核即可在广告平台只开户投放
|
||||
### 国内测试：资质审核、渠道多、相对复杂
|
||||
- 涉及微信小程序、抖音小程序、APP三种形态，资质要求复杂
|
||||
- 需提前准备软著、小程序备案、账户、支付接入等基础条件
|
||||
公司已拥有100多个软著资源，可复用，无需重复申请
|
||||
## 标准化流程建设路径
|
||||
### 角色重构
|
||||
- 发行主导测试策略制定(方向、目标、链路设计)，统一协调财务、中台、研发等模块，减少项目组自行推动的压力
|
||||
### 资源及流程前置
|
||||
- 将通用包体准备、账户开户、软著管理等前置事项提前储备
|
||||
- 按测试类型分类管理：测画风、测玩法、测转化，明确不同测试类型的测试方案及所需物料
|
||||
### 流程固化
|
||||
- 复盘首次测试中的明显卡点，在后续流程中规避
|
||||
- 建立标准化测试流程/机制
|
||||
- 深圳与厦门发行团队统一执行标准，提升协同效率
|
||||
## 理想测试周期目标
|
||||
- 理想测试上线时间：3~5天内上线
|
||||
- 理想结果产出时间：7~8天内出结果
|
||||
- **最终目标：一周内完成测试并输出结论**
|
||||
# 一、工作内容概述
|
||||
# **二、珍珠采集与护身符系统研究结论**
|
||||
## **背景：首发版本会议中关于采集珍珠系统的讨论**
|
||||
|
||||
> [嵌入电子表格: QvCbsE4rqhH0VRtNIc6c...]
|
||||
|
||||
三种方案在结果上趋同，都会产生**筛选**行为。区别在于筛选的驱动力是"恶心感"还是"利益感"。对官方而言，原护身符的产出控制可能更稳定，因为互惠符会推高整体产出且不可控
|
||||
**最终会议倾向：****按原规则推进**
|
||||
**理由：****改动收益、社交影响和数值影响都缺少验证，不应在缺证据时直接改造**
|
||||
|
||||
|
||||
|
||||
## **会后研究核心判断**
|
||||
**珍珠采集 + 护身符是花园经营品类的标配基础设施，不是《我的花园世界》的差异化设计。** 早在《鲜花小镇》时期就已有"抓花农 + 盾牌阻挡 + 被挡者获金币"的完整组合，《秘密花园HD》同样存在高度同构规则
|
||||
|
||||
## **基于官方概率公示的收益分析**
|
||||
官网"六、采集珍珠相关公示"确认：
|
||||
- 雇佣成功率 90%（系统自然失败率 10%，护身符是在此之上的额外阻挡）
|
||||
- 珍珠数量分布：200 颗概率最高（47%），期望值约 215 颗/次
|
||||
- 1 雇佣书 = 1 次雇佣，1 宝箱 = 100 珍珠
|
||||
**每日免费产出推算：**
|
||||
- 每日 2 次免费雇佣 → 约 1.8 次成功 → 约 387 珍珠 → **约 3.8 个宝箱/日**（无阻挡）
|
||||
- 若好友池中约 30% 开启护身符 → 实际约 **2.7 箱/日**
|
||||
- 差距约 1 箱/天
|
||||
**每箱产出结构：**
|
||||
- 约 71% 概率出单个培育材料/土壤（28 种全覆盖但每次只有 1 个）
|
||||
- 约 12% 中档资源（元宝 10/金币 5000/水滴·加速·花坊币各 10）
|
||||
- 约 12% 高价值（大量材料 ×15、元宝 188/88、金币 80000）
|
||||
- 约 5% 经验
|
||||
**关键结论：被阻挡 1 次的实际经济损失极小（约 1-2 个培育材料），但心理框架是"50% 每日免费配额被另一个人作废了"。** **经济影响和心理影响严重不对称**
|
||||
## **护身符在品类中长期存在的假设**
|
||||
**花园经营日常循环是纯 PVE，珍珠采集/抓花农是****让玩家每天必须面对具体好友头像、做出选择、并产生区分认知的系统**
|
||||
**护身符的存在让"点好友"不退化为纯挂机：**
|
||||
- 有成功/失败的不确定性
|
||||
- 失败有可归因对象（不是"概率不好"，是"那个人挡了我"）
|
||||
- 产生"谁好用、谁不好用"的区分认知
|
||||
**护身符结构的特殊性：被雇佣方无损失却可阻挡。** 这在偷菜/Coin Master 等经典"攻防"设计中不存在（那些是保护自己资源）。**花园品类选择让"阻挡"变成一个****无自利动机的社交信号****——****"不使用护身符"成为零成本的友好表达，任何玩家都能做到**
|
||||
|
||||
|
||||
**"雇佣采珍珠"在公会竞赛任务池中占 7.38%**
|
||||
珍珠采集不只是独立材料补充系统，已接入组织目标。公会竞赛期间被护身符阻挡的"感知损失"更大——损失的不仅是个人材料，还可能是对公会的贡献进度。这可能是护身符引发社交筛选的真正放大器
|
||||
## **结论**
|
||||
品类标配 + 无法明确指标提升 + 最坏只是边缘摩擦 → **首版按原规则上**，埋数据点，定义改动触发条件。不应占据首版核心设计辩论时间。** 公会竞赛节奏、商业化释放时序、压力曲线才是真正影响成败的设计层**
|
||||
# **三、复刻项目"策划觉得该改"的判断方法论**
|
||||
从珍珠采集争议中抽象出的通用判断流程，适用于所有复刻项目中的设计分歧
|
||||
## **核心原则**
|
||||
**复刻项目的默认姿态应是"先原样跑通，有数据后再改"，而不是"觉得不好就先改"**
|
||||
**原因**：
|
||||
|
||||
> :writing_hand:
|
||||
## **判断流程**
|
||||
策划直觉"这里不好"
|
||||
│
|
||||
├→ 1. 品类标配 vs 目标产品独创？
|
||||
│ ├→ 品类标配 → 证据门槛高（需数据反对经过多产品验证的设计）
|
||||
│ └→ 目标产品独创 → 证据门槛中等（只有一款产品验证过）
|
||||
│
|
||||
├→ 2. 改了后能预期哪个指标提升？
|
||||
│ ├→ 能明确（如留存、付费率、好友添加率）→ 可设计 A/B test
|
||||
│ └→ 不能明确（只是"感觉好点"）→ 优先级降低
|
||||
│
|
||||
├→ 3. 不改的最坏后果是什么？
|
||||
│ ├→ 可能损害核心留存/付费 → 值得优先验证
|
||||
│ └→ 边缘体验摩擦 → 排到有数据时再说
|
||||
│
|
||||
└→ 4. 执行建议
|
||||
├→ 首版按原规则上
|
||||
├→ 埋好数据追踪点（被阻挡后删好友率、7日留存、系统日活跃占比等）
|
||||
└→ 定义改动触发条件（"如果指标 X > 阈值 Y，则启动 A/B test"）
|
||||
## **"原版不改"是什么级别的证据？**
|
||||
"不改"可能意味着：
|
||||
- 他们有数据证明它正向 → 不该改
|
||||
- 影响太小不值得排期 → 可改可不改
|
||||
- 改动风险高于收益（线上经济牵连）→ 不是因为好，是因为改不动
|
||||
- 品类惯性，所有竞品都这样 → 没人验证过替代方案
|
||||
**多款品类产品长期保留同一结构，至少证明它"不致命"。但"不致命"不等于"好"**
|
||||
策划不适感的正确用法：**作为调查触发信号，不是改动依据**
|
||||
# **四、发行测试流程优化讨论**
|
||||
**聚焦测试周期长、跨部门协同低效问题，推动建立可复用的标准化工作流**
|
||||
## 测试流程现状与痛点
|
||||
### 测试周期长（关键瓶颈）
|
||||
- 当前测试周期约20天，从对接到上线耗时过长
|
||||
- 包体准备复杂：**无测试包体储备**，线上项目如GOS需协调梦加及厦门项目，大碰撞欧美包需重新打包、测试、上架
|
||||
- 商品页定制耗时：为不同美术风格配套定制商店页，拉长物料筹备周期
|
||||
### 必须依赖线上项目包体（刚性约束）
|
||||
- 仅测点击率可投落地页，评估转化成本必须有通过审核的应用商店及可安装包体
|
||||
- 转化成本评估需拥有完整测试链路：**广告 **> **应用商店 **>** 下载转化**，无法跳过
|
||||
### 缺乏系统性支持（组织问题）
|
||||
- 当前测试链路中各流程高度依赖项目组临时发起，且主要靠项目组推动全流程，无系统性支持
|
||||
- 发行、商务、资质、财务等职能未形成协同机制
|
||||
- 未来如需进行国内测试，前置工作更多更复杂，如软著申请、小程序备案、账户开设等前置准备工作需耗时长达1-2个月
|
||||
- 流程零散、跨部门无协同，导致人力与沟通成本浪费
|
||||
## 国内与海外测试差异
|
||||
### 海外测试：**模式成熟、渠道单一、相对简单**
|
||||
- 可临时调用已有线上包体进行测试，流程顺畅
|
||||
- 新建应用商店通过审核即可在广告平台只开户投放
|
||||
### 国内测试：资质审核、渠道多、相对复杂
|
||||
- 涉及微信小程序、抖音小程序、APP三种形态，资质要求复杂
|
||||
- 需提前准备软著、小程序备案、账户、支付接入等基础条件
|
||||
公司已拥有100多个软著资源，可复用，无需重复申请
|
||||
## 标准化流程建设路径
|
||||
### 角色重构
|
||||
- 发行主导测试策略制定(方向、目标、链路设计)，统一协调财务、中台、研发等模块，减少项目组自行推动的压力
|
||||
### 资源及流程前置
|
||||
- 将通用包体准备、账户开户、软著管理等前置事项提前储备
|
||||
- 按测试类型分类管理：测画风、测玩法、测转化，明确不同测试类型的测试方案及所需物料
|
||||
### 流程固化
|
||||
- 复盘首次测试中的明显卡点，在后续流程中规避
|
||||
- 建立标准化测试流程/机制
|
||||
- 深圳与厦门发行团队统一执行标准，提升协同效率
|
||||
## 理想测试周期目标
|
||||
- 理想测试上线时间：3~5天内上线
|
||||
- 理想结果产出时间：7~8天内出结果
|
||||
- **最终目标：一周内完成测试并输出结论**
|
||||
Reference in New Issue
Block a user