Early Reader 2020 调整

我在 Patreon 上开放 Early Reader 这一档有一年多了，感谢大家长期的支持，让我来聊聊这一年的通过经营 Patreon 学到的东西吧。

Early Reader 这一档每个月收 $1 的费用，对应的好处是提前一周阅读我最新发布的文章。（事实上我推迟了文章在其它平台发布的时间，同时在 Patreon 上设置了解锁时间。）在这一年内我获得了 9 位朋友的支持，现在仍然活跃的有 5 位。

我觉得 Early Reader 这一档并没有达到我原来的预期。我原本设想这一档能够通过足够低的价格获得尽可能多的读者支持，但实际上没有足够多的人愿意为「提前一周」这个福利而付费。我在跟 Joma 聊天时他提醒了我一件事情，「你不应该根据『你需要付出多少』来定价，而要根据『别人能获得多少』来定价，提前一周阅读对读者来说其实不值钱」。我觉得这个视角是对的，所以我准备对 Early Reader 这一档作出调整。

我从读者的角度来思考什么有价值，我觉得主要是两方面吧：

1. 获得我不对外公开的独家内容。
2. 能够真正的激励我创作更多的内容。

为此我新开了两档，分别叫做 Coffee Supporter ($5) 和 Sushi Supporter ($30)。这两档的价格比原来的更高，但请我吃饭（尤其是吃寿司）这件事情确确实实能够激励我干活。我有一个猜想，很透明地分享一下吧：如果我的读者觉得他们给我的是看得着摸得到的实物（食物），那会比原来虚无地付 $1 但不知道这 $1 有什么具体含义更乐意付费。（你们可以在评论区告诉我这个猜想对不对。）

此外我会开始做不对外公开的独家内容，专门给付费读者看。一开始主要还是文章，之后我会探索音频和视频。这些内容如果是长篇的话，我可能会免费发布其中一部分在公开的博客上，但不会发布全部。

最后说一下现在 Patreon 上的 Early Reader 这一档会如何迁移。我现在已经对新读者关闭了这一档，并且计划在 2020 年 1 月完全终止这一档，那意味着如果你到时候仍然使用这一档的话 Patreon 就会把你的付费订阅取消掉。如果你愿意升级到 Coffee Supporter 或 Sushi Supporter 的话，你可以在那之前进行升级。升级后会保留原有的福利，同时获得上述新增福利（不对外公开的独家内容）。

如果你是在我 Patreon 以外的博客上看到这篇文章，欢迎来 Patreon 付费支持我。如果你觉得美元付费对你来说并不方便，请在评论区留言告诉我，我正在努力开通支持人民币支付的对应版本。

Career Coaching 2020 新价格

我的 Career Coaching 将在 2020 年初开放更多名额，同时进行年度价格调整。新学生的价格为每小时 $300。2019 年内或更早加入的学生将能继续获得优惠，优惠价将在 2020 年 1 月统一调整到每小时 $200。

对于已经在 Patreon 上进行付费的现有学生，我会在 12 月开放新的一档 $200 的服务，请你们把自己的帐号从现在的 $100 或 $150 一档调整到 $200 一档，然后我会在 1 月删除 $100 和 $150 这两档。（我到时候会发消息逐一通知你们。）

对于等待新名额的学生，我将会在 12 月放出 $300 这一档。如果你 12 月就在 Patreon 上加入的话，系统会在 1 月头扣钱，我会在 12 月跟你约好 1 月份开始的 bi-weekly 30 minutes 1:1。

《牛油果烤面包》满月回顾（Part 3 - 统计数据）

在上一篇文章里我讲述了《牛油果烤面包》的录音和剪辑过程，接下来我们看看听众订阅和收听的数据如何。

---

我在第一篇文章里面提到我们用 Anchor 把播客自动发布到多个平台，同时我们手动发布到喜马拉雅和企鹅 FM。如果我们要看数据，我们就必须一个一个平台地看。

• Anchor：Anchor 提供「播放数」和估算的「听众数」，同时提供听众的国家、播放平台和设备分布。Anchor 会统计每一集每一天的播放次数。（参考截图）
• Apple Podcasts：Apple Podcasts Connect 不提供「订阅数」只提供「设备数」，所以无法知道有多少人订阅了。Apple 强调的是总收听时间，我们在过去的 60 天内有 96 个小时的收听时间，这样就可以推算出来每台设备 85 分钟的收听时间。此外这 96 个小时里 84% 来自于订阅听众，但这还是无法推算出订阅数。具体到每一集，Apple 同样提供设备数和总收听时间，同时提供节目内的留存率，也就是用户听到第几分钟第几秒钟就流失了。（参考截图：1 2）
• Spotify：Spotify 提供「播放次数」、「播放超过 60 秒次数」、「听众数」和「订阅数」。后面两个都是根据 Spotify 注册用户进行计算的，所以不存在多次在不同设备播放导致的重复计算。我们现在有 153 个订阅用户，但每期节目只有不到 20 次播放，意味着 Spotify 的用户经常订阅但不收听。Spotify 为每一集提供留存率，以及听众的性别和年龄分布。(参考截图)
• Google Podcasts：Google Podcasts 本身并不提供任何的数据，只要 RSS 被 Google 抓取了就会显示在 Google Podcasts 里。有意思的是，Google Play Music Podcast Portal 可以认领 podcasts，但我认领后还没能看到任何数据，不知道这个产品现在到底是否还活着，还是因为不会有人在 Google Play Music 里面听 podcasts。暂时来说，我们无法从 Google 获得任何数据。
• Castbox：Castbox Creator Studio 提供节目的订阅数、播放数和每一集的播放次数。（此外，因为 Castbox 提供了评论系统，所以作为管理员可以管理用户评论。）
• Breaker：Breaker 自动收录第三方的 RSS，对于不是在 Breaker 上创建的 podcasts 无法认领也无法获取数据。
• Overcast：Overcast 自动收录 Apple Podcasts 已经收录的 RSS，并且不提供认领。有意思的是，Overcast 在抓取 RSS 时通过 user agent 来上报订阅数，但由于我们使用 Anchor 提供 RSS 所以无法截获 user agent 获取订阅数。
• Pocket Casts：Pocket Casts 接受 podcasts 提交，但不提供认领和数据。
• RadioPublic：RadioPublic 自身不提供任何的数据分析，但可以使用 Google Analytics 收集数据。不过只有付费用户才能使用这项功能，所以我并不知道 RadioPublic 会向 Google Analytics 汇报什么数据。
• Stitcher：Stitcher Partners 提供播放数、播放时间和听完率。
• 喜马拉雅：喜马拉雅提供「订阅数」和「播放数」，以及每周新增听众的留存率。喜马拉雅不提供节目内的「留存率」但提供「跳出率」，虽然本质上是一样的数据但呈现出来的曲线就完全不一样的。（「跳出率」是「留存率」的倒数。）此外喜马拉雅提供听众的省份、城市和性别分布。

总结一下：这些平台提供的数据各不一样，有些平台基本上不提供什么数据。这就导致我们无法轻易地整合数据，分析听众喜好，然后优化将来的节目。现阶段我们能做的是，尽量把用户带往几个提供数据分析的平台，然后依靠这几个大平台的数据做决策。

长远来说，我觉得我们可以做自己的平台入口，让用户可以直接在我们自己的网站上播放甚至是订阅，这样我们就可以自己收集一部分的统计数据了。当然，如果用户喜欢用其它平台的 app 进行订阅和播放我们依然无法收集到那部分的数据，但至少我们能收集多少是多少吧，这对我们优化选题和节目内容很重要。

---

说完数据之后，我们接下来可以说说选题。如果你想知道我们是如何进行选题的，欢迎通过邮件或 RSS/Atom 订阅我的博客，保证你不会错过下一次关于选题的文章。

追踪短地址的小工具：Trace URL

我写了一个追踪短地址的小工具，输入任何短地址（或普通带重定向的地址），它就能找到原地址显示给你看。我把它叫做 Trace URL，欢迎大家来使用。这是一个 PWA (Progressive Web App)，所以 Android 用户可以把它添加到首屏，添加后就可以把短地址「分享」给 Trace URL 进行追踪。

这个项目是完全开源的，不过源代码分布在多个 GitHub 项目当中。traceurl-web 包含了 PWA 客户端代码。这个项目使用 Create React App 创建，然后使用 Material UI 做样式模板，最后手工编辑了一堆 metadata 使它成为一个好用的 PWA。在这里我分享一个比较小众的 PWA 知识吧，也就是如何让 PWA 接受来自 Android 分享的数据，这需要在 manifest.json 里面添加一个叫做 share_target 的信息，例如说：

{
  "share_target": {
    "action": "/",
    "method": "GET",
    "enctype": "application/x-www-form-urlencoded",
    "params": {
      "title": "title",
      "text": "text",
      "url": "url"
    }
  }
}

添加 share_target 信息后，只要 PWA 被添加到首屏，它就能成为 Android 系统的分享目标。需要注意的是，Chrome for Android 有个已知的 bug，分享地址时会把地址传输给 text 参数而非 url 参数。所以在处理传入参数时我们需要同时看 text 和 url，哪个有值就处理哪个。

这个 PWA 背后实际调用的 API 在 traceurl-api 项目里。这个 API 其实只是对 traceurl 库做了个简单的封装，这个库才是真正负责跟踪短地址的。这样层层封装只是为了好玩，让我能够尝试一些新技术，学习新知识。例如说，traceurl 其实是一个 package，我原本把它发布到 NPM Registry 了，后来 GitHub 发布测试版的 GitHub Package Registry 时我就试用了一下，把 traceurl 发布到那里去然后在 traceurl-api 里面引用。这就让我理解到了到底为什么 GitHub 要做自己的 Registry。（到底是为什么？我另外写一篇文章解释。）

这次就先说这么多吧，大家记得来试用一下 Trace URL 哦，好用的话记得添加到 Android 首屏哦！下次我再写文章讲述 GitHub Package Registry，感兴趣的话请记得通过邮件或 RSS/Atom 订阅本博客。