对于类似当当、京东、新蛋这样拥有海量商品目录的商家来说，全靠手工去找出针对每种商品的关键词然后上传到 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 里可以：
[code lang=’ruby’]
10.times do
…
end
[/code]
当然跳过的话一定要记录在 log 里。
对于一批数十万的关键词，远渡重洋到达 Google 的服务器至少需要许多个小时甚至许多天（无数次 HTTP 请求），在这段时间内，断电、断网的几率都是有的，我前阵子比较倒霉，都遇到了。后来学精了，遇到大批量操作都事先跟相关人员确认一下电力供应和网络状况，可是仍免不了大楼网络被攻击之类的事情发生。有一次甚至是一位同事好心帮我“开机”，把正在运行任务的服务器给关了……
做这种事本来就是压力很大的，一不小心银子就像流水一样白白花出去了，比如你买对了关键词，指错了链接 🙂 在压力很大的情况下又要面对许多的不确定因素，就更加刺激，更有挑战性了。