Back to Details

oss-growth-attribution

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

OSS Growth Attribution

OSS增长归因

Produce an auditable growth reconstruction, not a generic marketing checklist.
生成可审计的增长重建报告，而非通用营销清单。

Workflow

工作流程

  1. Resolve the canonical repository and validate it against the product domain.
  2. Fetch GitHub repository metadata, releases, earliest commits, and timestamped stargazers.
  3. Build a star timeline with daily resolution around spikes and monthly resolution elsewhere.
  4. Search GitHub Trending, Reddit, Hacker News, Product Hunt, X, LinkedIn, Instagram, TikTok, YouTube, developer media, technical blogs, and localized communities.
  5. Extract original content URLs; never substitute search-result URLs when an original URL is available.
  6. Normalize items to the evidence schema.
  7. Align publication times with star velocity using the attribution model.
  8. Divide history into preparation, community seed, accumulation, breakout, localization/SEO, and ecosystem stages. Omit unsupported stages.
  9. Report representative content per channel with hook, format, audience, funnel role, and original link.
  10. List channels searched but not evidenced. Absence of public evidence is not proof an event never happened.
  1. 确定规范仓库并根据产品领域进行验证。
  2. 获取GitHub仓库元数据、发布版本、最早提交记录及带时间戳的星标用户数据。
  3. 构建星标时间线：在峰值时段采用日分辨率，其他时段采用月分辨率。
  4. 搜索GitHub Trending、Reddit、Hacker News、Product Hunt、X、LinkedIn、Instagram、TikTok、YouTube、开发者媒体、技术博客及本地化社区。
  5. 提取原始内容URL；当存在原始URL时，绝不使用搜索结果URL替代。
  6. 将条目标准化为证据 schema格式。
  7. 使用归因模型将发布时间与星标增长速度对齐。
  8. 将项目历史划分为筹备期、社区种子期、积累期、爆发期、本地化/SEO期及生态系统阶段。省略无证据支持的阶段。
  9. 按渠道报告代表性内容，包含钩子、格式、受众、漏斗角色及原始链接。
  10. 列出已搜索但无证据支持的渠道。缺乏公开证据并不代表事件从未发生。

Source priority

来源优先级

  1. GitHub REST API and repository commits/releases
  2. Original posts, videos, launch pages, and project-owned pages
  3. Independent archives or channel-specific analytics pages
  4. Search result snippets only as discovery or dated snapshots
Use the API playbook. Follow the environment's web-access skill for browsing.
  1. GitHub REST API及仓库提交/发布记录
  2. 原始帖子、视频、发布页面及项目自有页面
  3. 独立存档或渠道特定分析页面
  4. 仅将搜索结果片段用于发现或作为带时间戳的快照
使用API操作手册。遵循环境的网页访问技能进行浏览。

Attribution guardrails

归因准则

  • Label API fields and original posts as 
    observed
    .
  • Label cross-source temporal conclusions as 
    inferred
    .
  • Label percentage shares as 
    modeled
    ; use ranges, never fake precision.
  • Do not credit a channel merely because it is common in OSS marketing.
  • Treat GitHub Trending as both an outcome of prior velocity and an amplification channel.
  • Do not sum overlapping platform effects as independent last-click conversions.
  • Without first-party traffic, UTM, or referral logs, state uncertainty of at least ±10–15 percentage points.
  • Never claim Product Hunt or Show HN impact without a canonical launch/discussion URL or strong corroboration.
  • 将API字段和原始帖子标记为
    observed
    （已观测）。
  • 将跨来源时间结论标记为
    inferred
    （已推断）。
  • 将份额百分比标记为
    modeled
    （已建模）；使用范围值，绝不使用虚假精确值。
  • 不得仅因某渠道在OSS营销中常见就将增长归功于它。
  • 将GitHub Trending视为既是前期增长速度的结果，也是一个推广渠道。
  • 不得将重叠的平台效应累加为独立的最后点击转化。
  • 在缺乏第一方流量、UTM或推荐日志的情况下，说明至少±10–15个百分点的不确定性。
  • 若无规范的发布/讨论URL或强有力的佐证，不得声称Product Hunt或Show HN产生了影响。

Required output

必需输出

Return an executive conclusion, attribution limits, stage timeline, channel contribution ranges, key content table with original URLs, hook analysis, unsupported hypotheses, exact-attribution instrumentation, and next-stage action plan. Every material claim needs a URL or a clear 
modeled
label.
返回执行摘要、归因限制、阶段时间线、渠道贡献范围、含原始URL的关键内容表格、钩子分析、无证据支持的假设、精确归因工具建议及下一阶段行动计划。每一个重要结论都需附带URL或明确的
modeled
标记。