对于类似当当、京东、新蛋这样拥有海量商品目录的商家来说,全靠手工去找出针对每种商品的关键词然后上传到 Google AdWords 账户,恐怕不是特别可行。AdWords Editor 是非常优秀的软件,然而它的 scalability 有限,假设有上千万级别的关键词,即使 Adwords Editor 恐怕也无能为力。

AdWords API 对于这样的情景再适合不过了。利用 API 可以将海量的关键词自动地上传到 AdWords,更能方便地将它们在 Google 的花费、表现跟自己的商品数据库对接,实现投入产出比的及时计算,对市场的变化作出快速反应,从线上广告的角度让利益最大化。对于如此大量的数据,仍然可以在很细的粒度上对广告做优化。

听起来很美好,可是实际做的话,就会发现一些让我们很烦恼的问题。Google 的系统足够稳定,非常值得信赖,我们的代码也很容易写得完全正确——AdWords 的 SOAP API 很简单,照着 Google 给的例子写就可以了吧。但是,网络却不是那么稳定,即使传输是基于具有纠错能力的 TCP,只要网线一拔,再强的纠错、重传也是白搭。所以光看 Google 的例子不行,程序需要更强的生命力。

记录足够的日志

不管你的程序多么 robust,遇到断电也得歇菜(除非你有昂贵的保障系统保证这个概率极低),所以至少你得知道它死在什么地方了,这时 log 是必不可少的。

此外,大批量的操作中必然会遇到一些错误,但又不必因为这些错误让任务就此停止,这样的错误就应该记录在日志中,等上传结束后供认核查。

check before add

这是 Google 的建议。广告创意上传之前要 check 一下,关键词也要。看到有问题的就删掉(或者加个解释传上去),然后再上传。应用了这个机制,即使你不小心尝试上传重复的关键词,也不会导致错误。

尽量恢复错误

最常见的问题出在网络连接上。TCP 再可靠,也终有它失败的时候。即使网线没被拔掉,在数百万的请求中,有那么一小撮出问题是很正常的。按照 Google 的例子,遇到任何异常都会退出。当你第二天早上兴致勃勃去查看昨晚开始的一个上传任务时,发现它实际上没上传几个就遇到异常退出了,可想而知会多么沮丧……

认清这一点,我们搬过来 Google 的示例程序之后,就应该改造一下 Google 的例子。每个 SOAP 请求都可能出现连接问题导致的异常,你需要捕捉它们。一旦发现网络连接方面的一场,就让程序休息一小会再重试——简单的粗暴的方法是将执行 SOAP 请求的代码包装在一个 infinite loop 里 (例如 while true)。

例如这个讨论:ssl broken pipe | connection reset by peer. 这个问题应该很多人都会遇到,AdWords 官方也给了不少答复,但是始终没有清晰的答案。我个人认为这大概跟 AdWords API 的实现没太大的关系,用上面的方法即可解决。

跳过不可恢复的错误

少数情况下,上面提到的网络异常会导致另一种情形,重试是没有意义的。即 Google 的服务器收到了你的请求(如添加了一个 ad group)并且正确处理,但是你却没有得到 Google 的 response,即无法得到该 ad group 的 id。重试的话,Google 会告诉你,名字重了。如果我们的程序够细致,这时就该跳过这个 ad group 了,如果是简单粗暴地捕捉到一切异常都重试并且是无限循环,那程序就死在这儿,并且不停的消耗 API units. 如果懒得做那么精细(不要把过多精力浪费在小概率事件上),稍微文雅一点,可以换成有限次数的循环,在 ruby 里可以:

10.times do  ...end

当然跳过的话一定要记录在 log 里。

对于一批数十万的关键词,远渡重洋到达 Google 的服务器至少需要许多个小时甚至许多天(无数次 HTTP 请求),在这段时间内,断电、断网的几率都是有的,我前阵子比较倒霉,都遇到了。后来学精了,遇到大批量操作都事先跟相关人员确认一下电力供应和网络状况,可是仍免不了大楼网络被攻击之类的事情发生。有一次甚至是一位同事好心帮我“开机”,把正在运行任务的服务器给关了……

做这种事本来就是压力很大的,一不小心银子就像流水一样白白花出去了,比如你买对了关键词,指错了链接 :-) 在压力很大的情况下又要面对许多的不确定因素,就更加刺激,更有挑战性了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Post Navigation