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的人可以更好地談論這個話題？