[分享创造] 做了个 PDF 分享工具:除了生成链接,我更想知道对方到底有没有认真看

最近做了一个比较小的 PDF SaaS ,叫 PDF to Link。

地址:

https://pdf-to-link.com/

最开始想做它,其实不是因为“PDF 转链接”这个功能本身有多难,而是我发现现有的 PDF 分享流程有一个挺明显的断层:

文件发出去了,然后呢?

比如我给别人发一个 20 页的 PDF:

  • 对方打开了吗?
  • 看到了第几页?
  • 哪几页停留时间比较长?
  • 是不是看两页就关掉了?
  • 最后有没有点击我希望他点击的链接?

如果只是通过邮件附件、Google Drive 、Dropbox 之类发出去,这些信息基本是看不到的。

于是就做了这个工具。


现在的基本流程

目前逻辑比较简单:

上传 PDF
↓
生成一个独立阅读页面
↓
得到分享链接 / QR Code
↓
别人通过浏览器阅读
↓
后台查看阅读数据

它不是把 PDF 转成 HTML ,也不是把 PDF 内容重新排版。

原始内容还是 PDF ,只是在浏览器里提供一个独立的阅读页面。

这样做之后,就可以在 PDF 外面增加一些东西,比如:

  • Logo
  • Favicon
  • 页面背景
  • CTA 按钮
  • 社交链接
  • 密码访问
  • Lead Capture
  • QR Code

我比较在意的其实不是这些外观功能,而是后面的阅读数据。


目前做了哪些阅读数据

现在后台主要统计:

  • Views / Reading Sessions
  • Visitors
  • Active Reading Time
  • Reading Depth
  • 每一页的 Engagement
  • Reader Location
  • Exit Page
  • Downloads
  • CTA Clicks

例如一个 20 页 PDF:

如果 100 个人打开:

Page 1  100
Page 2   92
Page 3   85
Page 4   81
Page 5   43
Page 6   38
...
Page 20  12

那至少可以看到第 5 页附近发生了比较明显的流失。

当然我不认为这就代表:

“第 5 页内容一定有问题。”

因为也可能用户已经找到了想看的信息。

所以我现在对 Analytics 的定位是:

它提供行为信号,而不是替用户解释行为。


Active Reading Time 我没有直接用页面停留时间

这里我之前纠结了一段时间。

假设:

用户打开 PDF → 切到另一个 Tab → 30 分钟以后回来。

如果简单用:

close_time - open_time

那结果可能会显示这个人读了 30 多分钟,但实际上完全不是。

所以现在 Active Time 更偏向统计:

  • 页面处于可见状态
  • 浏览器 Tab 是 active
  • 阅读器存在实际活动

当然,这依然不能证明用户“认真阅读”。

我觉得只能做到尽可能接近真实行为,不能把它包装成“阅读理解检测”。


为什么不用 Google Drive ?

这个问题应该是最容易被问到的。

我自己的理解是,它们解决的问题不完全一样。

Google Drive / Dropbox

更偏:

  • 文件存储
  • 文件夹管理
  • 权限
  • 团队协作

PDF to Link

更偏:

  • 对外发布一个 PDF
  • 提供独立阅读体验
  • 品牌展示
  • 查看阅读行为
  • 引导下一步操作

所以如果只是:

“我要给同事传一个 PDF 。”

我自己也会直接用 Google Drive 。

但如果是:

  • Pitch Deck
  • Proposal
  • 产品目录
  • Portfolio
  • White Paper
  • 报告
  • 培训资料

这类 PDF ,我觉得“分享之后发生什么”会更有价值。


一个我目前还没完全想清楚的问题:下载到底应该默认开还是关?

这个目前我自己也比较纠结。

如果允许下载:

优点:

  • 用户可以保存
  • 使用习惯自然
  • 离线阅读方便

缺点:

PDF 下载以后,后面的阅读行为就完全不可见了。

如果禁止下载:

优点:

  • 数据比较完整
  • 更适合一些 Proposal / Pitch Deck

缺点:

  • 用户可能觉得限制太强
  • 真正想下载的人可能截图或者用其他方式保存

所以目前我更倾向于:

让发布者自己选择。

但不知道 V 友们实际使用时更喜欢哪种默认值。


另外一个问题:Raw PDF URL 还是 Viewer URL ?

我现在产品默认生成的是阅读页,例如:

example.com/page/xxxxx

而不是:

example.com/file.pdf

因为只有 Reading Page 才能加 Analytics 、Password 、CTA 等东西。

但是实际调研下来,确实还有一批用户搜索的是:

“我就想要一个真正以 .pdf 结尾的 URL 。”

特别是开发/API/嵌入类需求。

所以我现在觉得这其实是两个完全不同的需求:

Raw PDF URL

更适合:

  • API
  • 程序直接读取
  • iframe / embed
  • 下载
  • 文件引用

Viewer URL

更适合:

  • 给人阅读
  • Analytics
  • Branding
  • Password
  • CTA

现在产品主要做后者。

这块如果 V 友里面有做文档系统或者 SaaS 的,也挺想听听你们实际更常遇到哪一种。


免费版目前怎么做

目前免费版:

  • $0
  • 1 个 Published PDF
  • 单 PDF 最大 50 MB

主要核心功能也可以体验。

我暂时没有做那种“上传一次以后所有东西都锁住必须付费”的模式,因为早期更想知道:

用户究竟会不会真的用这个东西,而不是注册以后就走。

现在最想验证的指标其实不是注册量,而是:

上传 PDF
↓
成功发布
↓
真的把链接分享出去
↓
产生真实 Reader Session
↓
回来查看 Analytics

如果这个闭环不成立,后面加再多功能意义也不大。


接下来我比较想做的

目前考虑的方向主要有:

1. 更细的 Reading Analytics

例如:

  • Page revisit
  • 阅读路径
  • Reader Session timeline
  • 不同链接来源的 engagement

2. Expiring Link

例如:

24 小时后失效
7 天后失效
指定日期失效

3. Custom Domain

这个已经在做更完整的体验。

例如:

docs.company.com/proposal

而不是平台自己的域名。

4. 更方便的销售/营销工作流

我之后可能会考虑:

  • Webhook
  • Zapier
  • HubSpot
  • Slack notification

例如:

某个 Proposal 被打开了
对方读到第 12 页
再次回来阅读

然后发通知。

不过这一块我暂时不想太早做,因为容易从一个很简单的 PDF 工具膨胀成一个很重的销售 SaaS 。


有几个问题特别想听听 V 友意见

如果你们平时会分享 PDF ,我比较想知道下面几个问题:

1. 你们实际有没有“想知道对方看到第几页”的需求?

还是说这个需求看起来合理,但实际上根本不会看数据?

2. 如果是 Pitch Deck / Proposal ,你更希望默认允许下载,还是禁止下载?

3. 你更需要 Raw .pdf URL ,还是浏览器 Viewer URL ?

4. 阅读 Analytics 里,你觉得哪个数据最有价值?

  • Active Time
  • Reading Depth
  • 每页停留
  • Exit Page
  • 是否重新打开
  • CTA Click
  • 其他?

5. 如果让你付费,什么功能才会真正让你付?

我自己现在比较怀疑单纯:

“上传 PDF → 生成链接”

其实没有太强的付费价值。

真正可能产生价值的还是后面的:

Analytics + Branding + Access Control + Workflow

所以现在还在验证这件事。


产品地址:

https://pdf-to-link.com/

如果大家愿意试的话,比较希望收到真实的吐槽,特别是:

  • 哪一步不好理解
  • 哪个功能完全没必要
  • Analytics 哪里看不懂
  • 分享页有哪些明显问题
  • 哪些功能你觉得我是在自嗨

这些反馈对我现在比“挺好的,加油”更有用。

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论