採集生意參謀似乎會發現它有些漏洞，在限制採集時做了訪問限制，返回加密，指數化，數據權限不嚴謹。 這些我們通過一些技術就可以破解。首先我們從技術上來說這些問題。
-
請求限制中transit-id：
![]()
訪問中必須帶的一個加密過的字符串，由前端頁面生成，服務器端校驗格式，並且只能使用一次。前段時間剛好遇到唯品會魔方羅盤也學了他們這一招，請求頭加上了一個鍵compassS，研究字串中包含了時間戳+請求的地址加密。雖然在加密時沒有生意參謀那麼複雜，卻做到了基本的防禦，時間和請求鏈接對不上就取不到數據。生意參謀中攜帶的transit-id在解密難度可以說很強，強到看不懂的地步，但卻沒有做實際意義的工作，沒有對時間，對鏈接及任何東西的校驗，就一個唯一性，但是這個tranist-id可以不同的地方生成，在任一地方可以用。好比拿到它就拿到一個一次性的萬能鑰匙，可這把萬能鑰匙卻是誰都可以生產。
-
返回數據加密：
![]()
雖然做了請求返回數據加密，卻在前端js暴露了解密，密鑰還固定爲sycmsycmsycmsycm，隨便加個動態的時間進去，解不就很麻煩了。然爾並沒有給採集者帶來麻煩，卻是自己麻煩一點解密然後生成一個數據對應的圖片。當然直接在服務器上放一些圖片，這裏顯示出來可能更安全，有人說圖片佔流量，那麼我們看看淘寶展示的各種高清大圖就不佔流量了。
-
指數化：
這裏不說了，能轉成對應的實際數據就行。比起京東指數，會有意義的很多。
-
數據權限
以改版以前，行業下的全品類全品牌是可以看的，店鋪，鏈接，關鍵詞什麼的都是不限制的。改版後改爲添加纔可監控標準版，品類監控10個，店鋪是30個，鏈接60個。但是我們很容易找到這個bugger，這些權限只是表面現象。我們組合的請求，可以拿 到這些數據。
爲什麼這麼幹，transit-id這麼難攻破的一個盾牌，卻不防禦，本來圖片化比加密做出來更難耗資源解析，本來很簡單的數據權限，都沒有做。但數據安全來說，雖然請求transit-id沒有防，其實採集的時候，我們發送請求的那一刻在服務器的session中早已記錄了賬號各項信息，每一條請求都是包含在他的數據庫中，這些是精準的。transit-id、加密、權限這幾層干擾並不具實際意義卻扮演了障眼法的角色。我們很慶興揭開密碼的同時，也許是被淘寶給反間計了。
那麼從商業角度來理解，從表面上生意參謀給我們一個越來越貴了，數據展示越來越少，越發看不懂的指數，不讓我們採集了，其實是更想通過客戶中使用了採集過程中留下來的痕跡挖掘客戶真正的訴求。只有這些不全面的數據，沒法看的指數才能區分真正的會使用和不會使用大數據的人，把真正的大數據的眼睛還給真正的電商人。
另一方面更精準的知道用戶的需求，才能更好的改進自己，優化自己。
同時通過這些限制，做了更好的防範，客戶的大數據，也只是小數據。說不定就發現了一些大量調用參謀過程中可能出現的對手，比如這些年崛起的電商平臺可能纔是淘寶想防的。
生意參謀作爲唯一一個全面的，精準的電商大數據平臺，是利器就看怎麼利用它。