solo 开发者的最小归因：知道「哪条链接带来了安装」

2026/9/17

背景与问题

不做投放也想知道：分享出去的链接、blog 文章、快捷指令模板、App Store 页面改动，到底哪条带来安装。重型归因 SDK（AppsFlyer/Adjust）对 solo 是过度配置。调研 Firebase 免费能力 + 轻量手段构成的最小归因集。

（来源访问日期均为 2026-09-17）

事实（LinkTrace 解说 2024-06）：独立开发者的归因核心是deferred deep link——自定义链接把 campaign 参数带过安装；无需重型 SDK 的轻量归因服务已成一类产品。
事实（Game Developer 2019 实录）：独立开发者视角的归因实践——先明确「要知道什么」（哪个渠道），再选 SDK；问题定义错，工具再重也白搭。
事实（Apsteq 2026）：独立开发者的多渠道归因建议从 Google 免费工具起步（first touchpoint → conversion），行为链路追踪不必一开始买。
事实（Android）：Play Install Referrer API 可拿到安装来源包名/referrer 参数——Google Play 层的免费归因基础。
推测：solo 的真实需求不是「全链路归因」而是「回答 3 个问题」：①这条分享链接带来多少安装 ②哪个 listing 改动有效 ③哪篇内容在带量。三个问题分别有免费解，不需要任何付费归因。

最小归因集：①共享链接全部走自建短链（opc-edge-api-workers 上加重定向+计数）②Android 用 Play Install Referrer 读参数 ③iOS 用 ASC 的 App Referrer 维度（App Store Connect 免费自带）。三件套合计零成本。
命名规则先行：utm/campaign 参数的命名表先定（渠道_位置_日期），否则三个月后数字无法解读。
不做的事：不装 AppsFlyer/Adjust（免费档也不装）——solo 的量级下维护成本大于信息收益；等有真实投放预算再上。
每月 1 次把短链计数与 ASC/Play 后台对账（10 分钟），并回答上面 3 个问题写进运营笔记（与 opc-monthly-review-30min 合并跑）。