oss-growth-attribution

开源项目增长归因

生成可审计的增长重建，而非通用的营销清单。

工作流

1. 确认规范仓库，并根据产品领域验证其准确性。
2. 获取 GitHub 仓库元数据、版本发布记录、最早的提交和带时间戳的 Star 用户。
3. 在增长高峰期前后按日构建 Star 时间线，其他时段按月构建。
4. 搜索 GitHub Trending、Reddit、Hacker News、Product Hunt、X、LinkedIn、Instagram、TikTok、YouTube、开发者媒体、技术博客和本地化社群。
5. 提取原始内容 URL；只要存在原始 URL，就绝不使用搜索结果 URL 替代。
6. 将条目规范化为证据架构。
7. 使用归因模型将发布时间与 Star 增速对齐。
8. 将发展历程划分为准备、社群种子、增长积累、爆发、本地化/SEO 和生态阶段。省略缺乏证据支持的阶段。
9. 按渠道列出具有代表性的内容，并注明切入点、形式、受众、漏斗作用和原始链接。
10. 列出已搜索但没有证据支持的渠道。缺少公开证据并不能证明某件事从未发生。

来源优先级

1. GitHub REST API 以及仓库提交记录/版本发布记录
2. 原始帖子、视频、发布页面和项目自有页面
3. 独立档案或特定渠道的分析页面
4. 搜索结果摘要仅用于发现内容或作为带日期的快照

使用API 操作指南。浏览时遵循环境的网页访问技能。

归因注意事项

• 将 API 字段和原始帖子标记为 observed。
• 将跨来源的时间关系结论标记为 inferred。
• 将百分比占比标记为 modeled；使用范围，切勿伪造精确度。
• 不要仅仅因为某个渠道在开源营销中很常见，就将增长归功于该渠道。
• 将 GitHub Trending 同时视为此前增速带来的结果和一个放大渠道。
• 不要将存在重叠的平台影响简单相加，视为相互独立的末次点击转化。
• 如果没有第一方流量、UTM 或引荐日志，至少说明存在 ±10–15 个百分点的不确定性。
• 没有规范的发布/讨论 URL 或有力的佐证时，绝不要声称 Product Hunt 或 Show HN 带来了影响。

必需输出

请提供执行摘要、归因限制、阶段时间线、各渠道贡献范围、包含原始 URL 的关键内容表、切入点分析、缺乏证据支持的假设、精确归因所需的埋点方案，以及下一阶段行动计划。每项重要主张都必须附 URL 或明确标记为 modeled。

加入出海社群与购买资料包 · 社群与资源

• 加入出海社群： 在微信添加 staywildgrow，留言「加入社群」即可。

• 购买资料包： 在微信添加 staywildgrow，咨询购买 Gingiris 出海资料包，价格为 599 元人民币。

• 加入全球增长社群： 在微信添加 staywildgrow，发送「加入社群」即可。

• 获取资料包： 在微信添加 staywildgrow，即可购买 Gingiris 出海资料包，价格为 599 元人民币。

社群与付费资料包均为可选入口，不影响本开源 Skill 的安装和使用。

社群与付费资料包均为可选内容；安装或使用此开源 Skill 均无需购买。