Facebook查询到广告组的转换在不同的机器上运行时返回不同的结果

Question

我们有一个查询，它在EC2实例上运行时返回的响应不同于在本地开发机器上运行时的响应。

的查询是相同的：

[AD_ACT_NUMBER]/adgroupconversions/?appsecret_proof=[APP_SECRET_PROOF]&include_deleted=false&start_time=1393372800&end_time=1393459200&aggregate_days=1&limit=500 

在本地dev的机器这个查询返回包括响应：

[{"adgroup_id"=>[SPECIFIC AD GROUP], 
"values"=> 
[{"start_time"=>1393372800, 
    "end_time"=>1393459200, 
    "conversions"=> 
    [{"action_type"=>"[CONVERSION I CARE ABOUT]", 
     "object_id"=>"[OBJECT ID]", 
     "post_click_1d"=>5, 
     "post_click_7d"=>7, 
     "post_click_28d"=>7}, 
    ...etc 

然而在EC2实例中，相同的代码，从而产生相同的查询，返回一个稍微不同的结果。

[{"adgroup_id"=>[SPECIFIC AD GROUP], 
"values"=> 
[{"start_time"=>1393372800, 
    "end_time"=>1393459200, 
    "conversions"=> 
    [{"action_type"=>"[CONVERSION I CARE ABOUT]", 
     "object_id"=>"[OBJECT ID]", 
     "post_click_1d"=>5, 
     "post_click_7d"=>6, 
     "post_click_28d"=>6}, 
    ...etc 

由于某种原因，转换次数少于1次。具有7的那个看起来是正确的，并且匹配 查询被粘贴到https://developers.facebook.com/tools/explorer时的结果以及在Facebook广告管理器中查看报告时的结果。

我们使用ruby和考拉来进行查询。考拉正在使用法拉第，并在运行时对代码进行了撬动，我已经能够确认，当它对Facebook进行原始http查询时，查询确实是相同的。两个查询都使用相同的访问令牌和相同的appsecret_proof。

起初我们认为这可能是一个时区问题，但看到两个请求具有相同的开始和结束时间，我们不知道如何。另外，虽然ec2实例处于UTC并且GMT处于开发框中，但UTC和GMT当前是同一时间。然后，我们检查了Koala或Faraday是否构建了缓存但没有发现任何内容，并且将查询更改为include_deleted = true以打破任何类型的缓存没有任何区别。

我们唯一的想法是，facebook api有一些基于请求IP的缓存，但是这似乎不太可能。

任何人有任何其他想法？

干杯

最大

Answer 1

鉴于你的证据的性质，我真的可以得出的唯一结论是，也许云实例正在与不同的Facebook的服务器和一个服务器是轻微的乱了与开发机器正好碰撞的那个同步？

我可以诚实地说我也见过一些奇怪的事情。我有一些广告代码，至今为止有230个单元测试（有些是真正的集成测试），他们对Facebook广告端点进行各种调用......有时，我看到测试执行之间的结果有所不同，估计终点由一个数量级的不同。当然，预计会出现一些变化，但从0.79到12.89之间的差异并不大。我所能得出的所有结论都是，Facebook必须拥有大量的服务器，如果他们有任何的负载平衡，并且可能一台服务器略有不同步，那么希望最终会找到另一台服务器是完全合乎逻辑的，

唯一值得关注的是，哪一个才是真相？

对不起，我没有比这更好的答案，如果查询和代码库确实是相同的，我没有看到任何其他真实的逻辑答案来解释为什么变化。我想这个答案确实没有解决问题，可能应该是一个评论，但问题是，在这种情况下什么是“正确的”答案？也许Facebook的人可以更好地谈论这个话题？