[{"data":1,"prerenderedAt":298},["ShallowReactive",2],{"blog-product-hunt-vs-china-pr":3,"blog-prev-product-hunt-vs-china-pr":76,"blog-next-product-hunt-vs-china-pr":227},{"id":4,"title":5,"author":6,"body":7,"canonical":60,"category":61,"cover":60,"date":62,"description":63,"draft":64,"extension":65,"keywords":60,"meta":66,"navigation":67,"noindex":64,"ogImage":60,"path":68,"seo":69,"seoDescription":60,"seoTitle":60,"stem":70,"tags":71,"updated":60,"__hash__":75},"blog\u002Fblog\u002Fproduct-hunt-vs-china-pr.md","海外发布和国内通稿：开发者工具的钱该投哪个","元析智能",{"type":8,"value":9,"toc":53},"minimark",[10,14,19,22,25,28,31,35,38,41,44,47,50],[11,12,13],"p",{},"这两件事经常被放在一张预算表里比，其实不是一回事。Product Hunt 这类海外发布，买的是发布当天的一次性曝光和第一批种子用户；国内媒体通稿，买的是搜品牌名时搜索结果里的占位。混在一起算性价比，永远算不清。",[15,16,18],"h2",{"id":17},"海外发布成本低素材要求高","海外发布：成本低，素材要求高",[11,20,21],{},"发布本身免费，成本在素材。需要一段 30 秒以内的演示视频、一句话说清楚产品解决什么问题、一个能直接用的注册入口。这三样缺一样，当天的转化就废掉一半。",[11,23,24],{},"时区也要算。发布最好选在美国时间的周二到周四上午，国内团队得有人熬夜盯评论区，前三个小时的互动量决定能不能进首页。我们有次偷懒，没人回评论，当天的位次就卡在第 12 名没上去。",[11,26,27],{},"2025 年 4 月我们陪一个 API 工具做过一次，当天 300 多个 upvote，注册 70 个，两周后还能归因到这次发布的注册是 120 个。这里面有一半来自发布后技术社区的二次讨论，不是发布页本身。",[11,29,30],{},"要注意的是投票。找朋友投可以，但别买票，平台识别得出来，被降权之后连正常的自然流量都没了。",[15,32,34],{"id":33},"国内通稿贵主要买搜索结果占位","国内通稿：贵，主要买搜索结果占位",[11,36,37],{},"报价从 800 到 3000 一家，打包 5 到 10 家通常 1 到 2 万。它的作用是让搜品牌名的人看到\"有媒体报道过\"，而不是带来直接流量。绝大多数通稿链接是 nofollow，对排名几乎没有帮助。",[11,39,40],{},"所以通稿的验收标准不该是排名，是搜索结果页面。发之前先截一张品牌词的搜索结果图，第 7 天再截一张对比，这是最省事的验收办法，比翻后台数据直观。发完之后搜公司全称，第一页有没有出现独立媒体的报道，出现了就算达标。",[15,42,43],{"id":43},"组合建议",[11,45,46],{},"早期别碰通稿。先把海外发布和技术社区做起来，成本低，用户质量也高，这个阶段花 1 到 2 万发通稿，很容易打水漂。",[11,48,49],{},"有稳定收入之后，再挑 3 到 5 家垂直媒体做深度稿，不做全网通稿。2024 年有个客户花 1.8 万发了 20 家，搜品牌名第一页全是同一篇稿子的转载，观感很差，后来他自己都不好意思让人搜。",[11,51,52],{},"一句话：海外发布是拉新动作，通稿是信任动作。预算紧的时候先拉新，别急着做门面。",{"title":54,"searchDepth":55,"depth":55,"links":56},"",2,[57,58,59],{"id":17,"depth":55,"text":18},{"id":33,"depth":55,"text":34},{"id":43,"depth":55,"text":43},null,"行业观察","2025-12-08","我们陪 4 个开发者工具做过海外发布，2 个做过国内通稿。两边成本差 10 倍，效果差在别处。这篇对比发布节奏、素材要求和可归因数据，给一个按阶段分配的组合建议。",false,"md",{},true,"\u002Fblog\u002Fproduct-hunt-vs-china-pr",{"title":5,"description":63},"blog\u002Fproduct-hunt-vs-china-pr",[72,73,74],"海外发布","媒体通稿","开发者工具","Dx5coQaHngKkBasFasm_AgVr2Ifzl_bLrjFrTzLdBDk",{"id":77,"title":78,"author":6,"body":79,"canonical":60,"category":215,"cover":60,"date":216,"description":217,"draft":64,"extension":65,"keywords":60,"meta":218,"navigation":67,"noindex":64,"ogImage":60,"path":219,"seo":220,"seoDescription":60,"seoTitle":60,"stem":221,"tags":222,"updated":60,"__hash__":226},"blog\u002Fblog\u002Ffaqpage-schema-ai-citation.md","FAQPage 该不该做：40 篇内容对照实验，差别只有 2 个百分点",{"type":8,"value":80,"toc":207},[81,84,87,90,93,96,99,102,105,108,164,167,170,173,177,180,183,186,189,192,195,198,201,204],[11,82,83],{},"FAQPage 结构化数据对 AI 引用的帮助，比你想象的小。2025 年 11 月到 12 月，我们拿 40 篇内容做了个对照：20 篇加 FAQPage schema，20 篇只在正文里改成 Q&A 格式、不加 schema。六周后引用率 27% 对 25%，差别落在噪声里。",[15,85,86],{"id":86},"先分清两件事",[11,88,89],{},"FAQ 富结果和 AI 引用是两码事。",[11,91,92],{},"富结果是搜索结果页上那个可展开的问答块。Google 在 2023 年 8 月收紧了展示条件，绝大多数站点已经拿不到了。指望 FAQPage 抢富结果，是在追一个 2023 年的玩法。",[11,94,95],{},"AI 引用是另一回事。引擎读你的页面，从里面挑一段回答用户。它挑的是文字，不是 JSON-LD。JSON-LD 是给搜索引擎解析用的，不是给大模型读的——大模型读的是渲染后的正文。",[15,97,98],{"id":98},"实验怎么做的",[11,100,101],{},"40 篇，同一个客户的技术博客，主题平均分在 API、部署、权限三块。A 组 20 篇加 FAQPage schema，B 组 20 篇不加 schema，但两组都做了同样的正文改造：把原来散在段落里的问答拆成独立 Q&A，问题用用户原话，答案压到 80 字内。",[11,103,104],{},"对照组是另外 20 篇没动过的老文章。",[11,106,107],{},"六周，每周三跑同样 50 个查询，记录引用。",[109,110,111,127],"table",{},[112,113,114],"thead",{},[115,116,117,121,124],"tr",{},[118,119,120],"th",{},"组别",[118,122,123],{},"处理",[118,125,126],{},"引用率",[128,129,130,142,153],"tbody",{},[115,131,132,136,139],{},[133,134,135],"td",{},"A",[133,137,138],{},"改格式 + schema",[133,140,141],{},"27%",[115,143,144,147,150],{},[133,145,146],{},"B",[133,148,149],{},"只改格式",[133,151,152],{},"25%",[115,154,155,158,161],{},[133,156,157],{},"C",[133,159,160],{},"未改",[133,162,163],{},"12%",[15,165,166],{"id":166},"结论",[11,168,169],{},"格式改造带来 13 个百分点的提升，schema 带来 2 个百分点。2 个点在我们这个样本量下分不清是效果还是波动。",[11,171,172],{},"所以顺序很清楚：先把正文改成机器好抓的问答，再考虑加不加 JSON-LD。反过来做，等于给一栋没打地基的房子装门铃。",[15,174,176],{"id":175},"schema-什么时候真有用","schema 什么时候真有用",[11,178,179],{},"有一种情况值得写：属性型数据。价格、评分、软件类别、支持平台、许可证，这些信息如果只写在正文里，引擎得靠猜；写成 SoftwareApplication 的 offers 和 aggregateRating，它读起来是确定的。",[11,181,182],{},"我们测过一个定价页，加 schema 前后，AI 回答里报对价格的比例从 60% 到 92%。这个提升是实的，因为它减少了歧义，不是增加权重。",[15,184,185],{"id":185},"那还要不要写",[11,187,188],{},"写，但排期往后放。我们的做法是内容改造完、跑一个月、确认引用开始动了，再统一补 schema。补的时候只补三类页：定价页、对比页、产品功能页。这三类页有属性数据，值得结构化。",[11,190,191],{},"博客文章不用每篇都补。40 篇博客的 FAQPage 标记，边际收益接近零，还增加维护成本——页面改版忘记同步 JSON，标出来的信息就和正文对不上。",[11,193,194],{},"工具能一键生成的东西，通常也不值钱。",[15,196,197],{"id":197},"别踩的两个坑",[11,199,200],{},"别在 schema 里写正文没有的内容。有人为了拿富结果，在 FAQPage 里塞了页面上不存在的问答，这属于欺骗性标记，被识别之后整站的结构化数据都会被降权。",[11,202,203],{},"别一页堆十几个 FAQ。我们见过一页 18 个问题的，正文读起来像客服手册，人看不下去，引用也没涨。5 到 8 个是合适的量。",[11,205,206],{},"做内容的人容易迷信技术标记，因为改 JSON 比改文章快。但这活儿，慢的那部分才是有效的。",{"title":54,"searchDepth":55,"depth":55,"links":208},[209,210,211,212,213,214],{"id":86,"depth":55,"text":86},{"id":98,"depth":55,"text":98},{"id":166,"depth":55,"text":166},{"id":175,"depth":55,"text":176},{"id":185,"depth":55,"text":185},{"id":197,"depth":55,"text":197},"技术SEO","2025-12-07","20 篇加 FAQPage 结构化数据，20 篇只改 Q&A 格式。六周后引用率 27% 对 25%，差别在噪声范围。真正起作用的是问答格式，不是那段 JSON。",{},"\u002Fblog\u002Ffaqpage-schema-ai-citation",{"title":78,"description":217},"blog\u002Ffaqpage-schema-ai-citation",[223,224,225,215],"结构化数据","FAQ","AI引用","hoGK6syLtwlPxPiBvNxLSFfhAZxagwpuyTwWj-yWplI",{"id":228,"title":229,"author":6,"body":230,"canonical":60,"category":286,"cover":60,"date":287,"description":288,"draft":64,"extension":65,"keywords":60,"meta":289,"navigation":67,"noindex":64,"ogImage":60,"path":290,"seo":291,"seoDescription":60,"seoTitle":60,"stem":292,"tags":293,"updated":60,"__hash__":297},"blog\u002Fblog\u002Fopen-source-commercial-funnel.md","开源版和商业版之间，缺的是三层页面",{"type":8,"value":231,"toc":280},[232,235,239,242,245,249,252,255,259,262,265,268,271,274,277],[11,233,234],{},"开源项目做商业化，最常见的断点是开源用户压根不知道有付费版，或者知道了不知道差在哪。2025 年 11 月我们给一个开源 BI 工具补了三层页面，到 2026 年 1 月，企业咨询从月均 4 条涨到 17 条，同期自然流量只涨了 12%，变化来自页面而不是流量。",[15,236,238],{"id":237},"第一层功能对照页","第一层：功能对照页",[11,240,241],{},"一张表，左边开源版，右边企业版，行是功能点。关键是这张表要诚实，开源版有的功能别写成企业版独有，用户一测就知道。",[11,243,244],{},"我们的写法是每个功能点后面加一句“为什么这么分”。比如“审计日志：企业版，因为涉及合规留存的客户通常需要 12 个月以上的日志”。这句话能挡掉大量不适合的咨询，销售那边反馈质量明显变好。",[15,246,248],{"id":247},"第二层场景页","第二层：场景页",[11,250,251],{},"用户不买功能，买的是“我这个场景能不能解决”。场景页的标题用行业加规模，比如“50 人以下 SaaS 团队怎么做数据看板”。一个场景一页，写清这套配置需要几个人、多少成本、开源版够不够。",[11,253,254],{},"这类页面是搜索流量的主力，“开源 BI 工具 小团队”这种词竞争不大，意图很准。我们第一批写了 6 个场景，其中两个成了自然流量前五的页面。",[15,256,258],{"id":257},"第三层迁移和采购页","第三层：迁移和采购页",[11,260,261],{},"这一层最容易被忽略。企业用户在做采购决策时会搜“XX 开源版 和 企业版 区别”“XX 私有化部署 要求”“XX 商业授权 价格”。这些词量小，但来的人已经在走流程了。",[11,263,264],{},"页面要写清四件事：部署方式、授权模式、支持响应时间、迁移成本。价格可以不写具体数字，但要给区间或者“按节点计费”这种口径，否则用户直接走了。",[15,266,267],{"id":267},"一个容易踩的坑",[11,269,270],{},"别把开源用户当潜在客户硬推。我们见过把升级弹窗塞进开源版界面的项目，社区反弹很厉害，issue 区一片骂声，最后撤了。商业化的入口放在文档、官网、邮件里，别放进产品里打扰使用者。",[11,272,273],{},"还有个判断：如果你的开源版用户里，企业占比不到 5%，先别做这三层页面，先想清楚企业为什么不用。页面能放大需求，不能创造需求。",[11,275,276],{},"还有个信号值得盯：从开源版升级到企业版的客户里，升级前访问过这三层页面的比例。我们客户是 70% 左右，说明页面在起作用，不是全靠销售硬推。",[11,278,279],{},"我们接这类项目前会先看一个数：GitHub 上来自公司邮箱的 star 和 issue 占比。低于 3% 的，商业化页面做了也是白做。",{"title":54,"searchDepth":55,"depth":55,"links":281},[282,283,284,285],{"id":237,"depth":55,"text":238},{"id":247,"depth":55,"text":248},{"id":257,"depth":55,"text":258},{"id":267,"depth":55,"text":267},"SEO","2025-12-09","开源项目转商业版，最大的流失发生在“我知道有企业版，但不知道要不要买”。我们补了三层页面，企业咨询量从月均 4 条到 17 条。",{},"\u002Fblog\u002Fopen-source-commercial-funnel",{"title":229,"description":288},"blog\u002Fopen-source-commercial-funnel",[294,295,296],"开源商业化","转化路径","页面设计","6rWtX7a3ts1V7u2Ue9xCMkLYCcv4HOr7rhktbXCZ_a8",1794088110224]