如何使用此决策树
一次只处理一个任务。将其写在卡片上，并按顺序回答问题。
团队往往就工具本身争论不休，这毫无结果。针对单个重复性任务（例如为零售客户每月导出引荐域名）进行争论，十分钟内就能得出具体数字。
让负责执行导出操作的人员参与此过程。他们最清楚哪些任务是真实存在的。
决策树
Semrush API 竞争对手：哪些席位任务可以迁移
取消席位是一个粗放的决定。按顺序逐一检查下面的决策树，只有经过所有问题筛选后仍适用的任务才进入计量计费。
决策树，按顺序
01
该任务是否需要关键词、排名位置或搜索量？
如果是，请停止。它应保留在 Semrush 或 Ahrefs 中。我们不销售关键词数据，任何诚实的比较也不会假装能。
02
该任务是否需要比大约一个月前更新的数据？
如果是，请再次停止。我们的索引大约每月刷新一次，因此发布周监控应属于每日更新数据的专业套件或 Google Search Console。
03
该问题是否关于链接、锚文本或域名强度？
如果是，请继续。引荐域名、backlinks、锚文本、顶级页面和 DR 正是 API 返回的内容。
04
是由人点击操作，还是由机器调用？
使用过滤器进行探索的人更适合使用 UI 界面。脚本、电子表格或自动化工具更适合通过每次 1 到 3 个信用的调用服务。
05
该任务每月运行次数是否超过 1 次？
如果是，随着运行次数增加，计量计费将更具优势。每次运行只需 1 次调用，最多 1,000 行数据，仅计费 1 次。
06
你能说出该输出结果的所有者吗？
没有所有者的任务就是应该删除的任务，而不是迁移的任务。删除它，同时节省信用额度。
按决策树排序的 5 个席位任务
| 席位任务 | 裁决 | 操作及成本 |
|---|---|---|
| 客户报告的每月 backlink 导出 | 迁移 | backlinks，2 个信用 |
| 300 个关键词的排名监控 | 保留 | 此处不提供 |
| 检查 1,500 个外联目标的 DR | 迁移 | bulk_dr，1 个信用 |
| 查看谁链接到 3 个竞争对手（而非你自己） | 迁移 | intersect，2 个信用 |
| 按关键词重叠度的内容缺口 | 保留 | 仅限关键词工具 |
一个明显的假设性示例
一家 5 人规模的代理商列出了 12 个重复性任务。其中 7 个由 1 名分析师执行链接抓取。这些任务迁移后，席位数量减少 2 个，其余 5 个任务保留在套件中。你的具体情况会有所不同；关键在于方法。
是否应该迁移席位，以及何时迁移？
Semrush API 竞争对手能替代 Semrush 席位吗？
并非所有任务都适用。关键词研究、排名监控以及任何需要比大约一个月前更新数据的任务应保留在套件中。计量链接 API 接管脚本和电子表格执行的链接抓取任务。
哪些席位任务最容易迁移？
以电子表格或客户文件为终点的重复抓取。每月固定日期运行的引荐域名导出是典型情况，每次调用成本为 2 个信用。
数据是否与席位显示的一致？
并非逐位一致。我们的域名评级（DR）是我们自有的对数评分，因此应通过几个月内的排名顺序来评估变化，而不是通过单次并排比较。
一旦第一个任务迁移，席位是否应立即取消？
第一周很少这样做。一个席位通常承载多个任务，而你迁移的任务可能并非其中成本最高的。
保留在套件中的任务及其原因
某些任务应保留在原处。迁移它们所花费的时间成本可能高于席位本身，且其支持的工作产出质量会下降。
如果任务依赖于关键词搜索量、跨越数周的排名追踪，或某人每天早晨打开查看的可视化报告，请将其保留在套件中。这些都不是链接问题，因此无论链接 API 定价多好，都无法回答这些问题。
关键词和搜索量问题
搜索量、关键词难度以及页面可针对的短语都位于链接索引之外。如果你的团队根据搜索量对内容创意进行分类，套件是完成该列表的工具。
不要尝试从链接数量重建该列表。引荐域名显示网站的强度，而非人们输入搜索框的内容。
随时间推移的排名追踪
排名图表需要对相同关键词进行重复的、带日期的观察。链接索引大约每月刷新一次，无论你查询频率多高，都无法生成该系列数据。
将追踪保留在原处，或购买按实际追踪关键词数量定价的排名工具。
人工点击浏览的仪表板
使用过滤器进行探索的人需要快速的界面和新鲜的抓取数据，这正是套件提供的。脚本永远不会打开过滤器面板。
因此，脚本执行的抓取任务才是应该迁移的。将探索功能留给喜欢它的人。
决策树之后的操作
维护一个已迁移任务的运行表。这将作为财务部门的证明。
每一行应包含任务、所有者、每次运行的信用成本、运行日期，以及它原本所在的席位或工具。经过 1 个季度后，你将清楚真正需要多少个席位。有些导出从未被阅读。该表使其可见。不要在迁移任务的同一周取消席位，因为 1 个月的并行运行能捕捉到决策树无法发现的意外情况。
Google Search Console 是你查询和点击数据的免费来源，因此任何需要这些数据的工作都不应首先包含在付费链接 API 中。
为每个迁移的任务指定所有者
每个迁移的任务都需要 1 个人来在出现故障时及时发现。没有所有者的 cron 行或电子表格公式会静默失败，第一个迹象是一份无人能解释的报告。
每个任务应指定 2 个人，且他们通常不是同 1 个人。
执行抓取的人
询问谁按下按钮或阅读输出。这个人知道导出是否仍然重要、使用了哪些列以及数据下一步流向何处。
将每次运行的信用成本告知他们，让他们看到自己习惯的成本。
支付席位费用的人
财务或团队负责人需要 1 句话的账单：该任务在信用额度上的成本，以及迁移后减少的席位数量。这句话比工具列表更容易获得批准。
如果无人能说出上次使用席位的人，那么席位是第一个候选对象，而不是任务。
1 个季度后阅读迁移任务表
1 个季度后，该表应回答 3 个问题：哪些任务已迁移、成本是多少以及哪些席位已取消。从底部向上阅读，从无人认领的任务开始。
假设 6 个迁移的任务在 1 个月内共花费 40 个信用。每个信用 $0.0001，总计 $0.004，这笔金额小到可以忽略不计，从而将席位行作为真正的决策依据。
从未运行的任务
一个从未运行的迁移任务也是一个发现。将其划掉，记录原因，并决定它是否真的需要。
闲置的席位在任务列表完整后通常会自行解释其存在原因。
1 个月后的意外情况
成本意外通常来自无人记得的第二次运行，而非调用价格。在归咎费率之前，先查找运行次数翻倍的任务。
保留该表用于下一个季度，以便比较有基准可依。
决策树未涵盖的边缘情况
某些任务处于两个答案的边界。例如，为关键词决策提供数据的链接抓取：抓取可以迁移，但决策应保留在关键词数据所在处。
季度董事会报告是另一种情况。它只阅读 1 次并归档。计量费用很低，但如果每次都由人工构建，一旦计算其工时，人工可能仍然是更便宜的选择。根据所有者的时间以及信用额度做出决定。
如有疑问，将任务拆分为 2 部分。将需要关键词的部分保留在套件中，将需要链接的部分迁移。迁移第二部分。
注意任务形态的变化。每月抓取变为客户端实时仪表板后，任务已从计量计费转回套件，因此应再次运行决策树。在同一个表中记录每次重新运行的日期。
团队提出的 2 个后续问题
之后的报告外观会不同吗？是的。我们的 DR 是我们自有的对数指标，公式为 round(100 log(ref_domains+1) / log(2 10^7))，因此它将不等于任何供应商的数字。为每个报告选择 1 个指标，并在几个月内保持固定，并先阅读 交换错误。
如果你想要 1 个工具和 1 个登录名呢？那么留在套件中并接受价格。计量计费仅在脚本化运行量高时才划算，如果团队中无人编写公式，他们在小时数上的损失可能超过节省的美元。在决定前请检查 成本表。
