iOS馬甲包審覈以及常見審覈問題
1、蘋果近期審覈動態分析
2、2018年App Store算法重大調整首次曝光一、蘋果近期審覈動態分析
1、機審越來越完善
衆所周知，應用在上架至App Store前，必須通過神祕的蘋果審覈團隊的審覈。能否在短時間內順利通過審覈，對App推廣節奏和策略、以及迭代等的應該是非常大的！
首先講一下提審的流程
目前應用提審的整個流程大體分爲五個階段，這個登錄過iTC後臺或操作過App上架的小夥伴應該都知道：Prepare For Upload（準備上傳）、Waiting For Review（等待審覈）、 In Review（審覈）、Pending Developer Release(等待開發者發佈)、Ready For Sale（準備銷售）。
其中 Waiting For Review（等待審覈）和In Review（審覈）這兩個階段是不受開發者控制的，也就是說，這兩個階段由審覈人員操控。
下面說一下機審和人工審覈
蘋果審覈大體分爲三部分，預審、機審和人工審覈。包上傳後首先進入的是預審，會被掃描API等，沒問題的話纔會在iTC裏出現 然後纔可以提交至 Waiting。
在審覈前期，也就是 Waiting For Review（等待審覈）階段一般是機審，去年鬧得沸沸揚揚的4.3就是通過機器掃描掃代碼；
機審不通過則直接被拒，通過後會進入人工審覈，即In Review（審覈）階段，這個階段主要看的是App的元數據，例如標題、描述、截圖等，以及檢測App的功能使用情況，常遇到的ipv6也在此處檢測。
判斷是進入了機審狀況還是人工審覈狀態，除了看時間外，還有一個方式，就是去看後臺，如果有美國iP登錄，應該就是人審了；如果只有App啓動但沒有深度訪問，說明在機審呢，正在掃代碼。
當然，利用上述兩種方式也可以來判斷App是機審被拒，還是人工審覈被拒，然後確定解決側重點。
目前機審機制越來越完善了，而且也越來越受重視，這個從2.1和4.3出現的頻率就可以看出來！其實蘋果重視機審也是可以理解，減少人工成本並增加審覈嚴格度，也更傾向於人工智能這個大方向！不過如果機審機制太完美，對我們可能不是好事，過審也許會越來越不容易。
2、審覈時間逐漸縮短，但延期審覈現象增多
雖然大家一直在吐槽蘋果的審覈時間，但相比於之前，例如7~8天階段、3~4天階段，現在已經很不錯了。而且通過近三個月的審覈數據對比，App審覈的週期又有了進一步縮短的趨勢。
蘋果曾在2017年6月WWDC大會上表示，接下來會進一步縮短審覈時間。從目前趨勢來看，確實是在進一步縮短。不過現在又出現了一個現象或者說處罰方式——延期審覈。
延期審覈一般針對的是大量同種類的App，比如遊戲（鬥地主等），還有涉及敏感題材的App，比如金融、彩票、VPN等。特別是對於遊戲，蘋果已經摸清了此類App開發者的套路（馬甲包、隱藏支付等），但由於一些開發者隱藏工作做得好，蘋果又無法拿到確鑿證據，所以只能故意拖延。如果被延期輕則需要十幾天，重則拖延1個月甚至幾個月。
有小夥伴可能想了解延期審覈後怎麼辦？在此說幾點，如果沒有明顯違規，除了打電話，在iTC後臺點【聯繫我們】這些方式外，還有一些稍微冒險的方式，申訴或加速審覈。如果這兩個方式還不行，又不想等，果斷換賬號重新提包吧！還有個方法是將免費App設置爲付費，但也只是可以縮短waiting時間，審覈的時間也可能會很久，這個不是很好管控。
3、蘋果審覈側重點不斷調整，且新的被拒理由層出不窮
蘋果審覈側重點不斷調整，且新的被拒理由層出不窮。用這句話來形容近期蘋果的審覈應該不會有人反對吧?
這個現象我們從近3個月被拒條款排行榜即可窺得一斑。當然這裏所說的“新的被拒理由”有些是一直存在的，只是沒有側重這方面審覈或者說審覈沒有升級到這一步而已。下面結合數據分析一下，裏面會涉及一些被拒現象的分析。
①如下圖所示，2017年12月，在統計的所有樣本數據中，條款2.3（元數據問題）佔據近乎四分之一的比例；其次是條款5.1.1（主要是用戶隱私問題），佔比約16.88%；而條款2.1（主要是App完成度問題，此時被拒大禮包還沒集中出現）以577例居第三。除此之外，Top5中還有5.2.1。
這裏說一下5.2.1吧，在因該條款被拒的App中，金融理財類App佔比較大，而關於此類問題的處理方式大家一般採取的是買賬號、代上架然後在線轉移、套殼然後採用登錄做區分等方式、PS等。不過隨着越來越多人使用，和監管的力度的加強，PS、套殼等過審機率已經沒有以前高了。
②在2018年1月被拒條款排行中，條款2.3（元數據）繼續位居榜首，緊跟其後的是原本在2017年12月排在第二名的條款2.1（App 完成度）。而新晉條款3.2.1以 231例，7.15% 的比例成爲第四名。
在因3.2.1被拒的App中，很多人是收到了下方的內容，要求提供營業執照、金融許可證等7項內容。對於3.2.1，現在已經出現了待操作、過審，我簡單說一下過審的App大體都做了啥吧！
1-3條要求的證照直接上傳或放在附件中。然後提供營業執照時，在營業執照中標出了營業範圍，例如證明經營範圍裏有網絡借貸信息中介服務等。
提供了該營業執照在國家企業信用信息公示系統（網址：http://www.gsxt.gov.cn/index.html）的查詢方式。提供增值電信業務經營許可證時還提供了增值電信業務經營許可證查詢鏈接:https://tsm.miit.gov.cn/pages/home.aspx
此外，雖然其他4點不如前3點重要，但也進行一一回復。
第4條是要求給出平臺的服務協議和條款；第5條是如發生爭議，應用程序和服務提供什麼樣的解決機制；第6條需要說明是在這種情況下有什麼責任，這些責任是否在條款中明確規定；第7條是涉及的責任各方如何追查。把這些內容都按照要求提交，並在截圖中標明瞭重點。
此外還提供了產品的介紹、與支付公司合作協議。其他大家可以自己去探索一下，提示一點：官方材料儘可能多。
③而在最近的2月被拒條款排行中，條款 2.1（主要是被拒大禮包），以28.48% 的比例佔據了榜首。緊跟其後的是條款2.3（元數據）。新晉條款 4.2（最低功能要求）以147例，5.94% 的比例成爲第五名。
因條款 4.2被拒的App多數是因爲功能過於簡單或缺失或審覈人員沒有get核心功能。對於這一問題解決方式除了按要求添加些小功能，對細節進行優化外，也可以考慮解釋產品可用性，例如用戶的需求，和其他產品區別等。
還有一點很想和大家一起討論一下。這陣子收到的人不少，就是1月28日集中出現的、叫很多人叫苦不迭的2.1大禮包。1.1.6、2.3、2.3.1、3.1.1、4.3等都被羅列其中，而審覈人員的要求是：你自己去排查吧！在被拒的App中，不僅包括金融，還有電商、遊戲等。
上圖是比較普遍的2.1大禮包，我們先看一下每條被拒理由和常規解決方式吧！
1.1.6 –包含虛假信息，功能或誤導性元數據
一般是因爲標題或者icon和截圖等有誤導的嫌疑，或有些關鍵詞是被蘋果列入黑名單的，例如紅包包、話費等，但審覈條款又沒有明確指出。對於上述情況的解決辦法是使用保守的文案或素材。
2.3.0 – 含有不經審覈也可更改App功能
如改變App功能的熱更新，這種情況需要把熱更新去除,或者對熱更新模塊代碼做深度混淆處理!
2.3.1 – 含有隱藏功能或爲記錄的功能，包括定向到賭博或彩票網站的開關。
常規解決方式：去除隱藏功能模塊代碼或將需要隱藏功能的代碼及定向跳轉鏈接網址做混淆處理，適當增加邏輯複雜度。3.1.1 –應用內購以外的支付機制來解鎖App中的功能或功能。
對於第三方支付,儘可能避免使用易掃描的SDK版本,推薦使用H5版本支付。支付跳轉鏈接相應的做屏蔽混淆處理。
4.3.0 –是另一款應用的複製品，或與另一款應用明顯相似。
被認爲是重複App或馬甲包，變更UI和名稱，填充無用代碼等，下面會具體講。
5.2.1 –未由擁有並負責提供該應用程序提供的任何服務的法律實體提交。
未提供 App 上架所需的行業資質，比如：金融營業許可證、遊戲版號等。這個上面講過些常規方式。
5.3.4 – 含有貨幣遊戲（如：體育下注、賭場遊戲等），但未提供相關許可資質。
同上，提供資質，審覈時最好不要勾選中國區，或使用海外賬號。
①如果App沒有違反上述任何一點，其實直接回覆沒有違反即可！當然，如果想增加過審機率也可以按照郵件中羅列的審覈指南一一進行解釋，說明自家 App 並不存在這些規則中的問題，儘可能描述詳細。如果回覆後並沒有推進，可以配合加速審覈或審覈申訴，不過需要注意，加速審覈次數不要用太多，審覈申訴可能引來審覈團隊更嚴格的審覈，需要謹慎。
注：2.1剛出現的時，即使App有違規行爲直接回復也是有可能過審的，但是目前有點用爛了，蘋果那邊應該是敏感了，目前過審機率極低，而且有可能被延期。
②如果App違反上述某點，建議認真修改後回覆蘋果，重點看上次或歷史被拒記錄，確定回覆側重點。如果回覆後並沒有推進，也可以配合加速審覈或審覈申訴，不過有延期等風險。
③除了這些方法，有人還用過一種方式過審，即用新賬號上傳，上面說過“蘋果審覈人員應該並沒有開始審覈，僅是針對App的歷史違規記錄或開發者賬號的違規記錄等發送了這封郵件。”但這種方式並不適合所有App，而且蘋果可能會發現新賬號的App和舊賬號以及舊App的關係而產生連帶處罰，要看運氣。
下面是小助手收集的幾個問題，在這裏做一下回復：
A、2.1有解嗎？有，目前出現了代過審，具體操作方式都是私下進行的，和5.2.1和3.2.1一樣，大家都去用，反覆刺激蘋果，審覈機制又會被更改。
B、只有更新的App纔有可能收到被拒大禮包？其實不是，收到這封郵件的App中既有新提交的App，也有要更新版本的App。
C、2.1是機審？目前數據和被拒的現象來看，主要是機審，人工審覈比例不高，多數是針對的代碼、App或開發者賬號的歷史違規記錄等發送的郵件消息。
pp的歷史違規行爲和賬號的歷史違規行爲都有可能觸發2.1大禮包。
當然除了以上被拒原因外，4.3（重複App）、IPv6、3.2（f）、PLA1.2等仍是被拒常見原因！下面說一下4.3。
4.3主要針對的是重複App，就是馬甲包，4.3被拒主要在機審階段，解決這個問題通常採用的方式簡單來說分以下幾步：
A、改名字；
B、修改素材及UI色調等，例如修改icon，修改主色調；
C、修改功能界面等，可改功能可做小開關；
D、填充代碼（最好50%以上）或註釋塊；
除以上步驟外，還需要注意相同的馬甲包提交至少要間隔一天以上，避免被同一個審覈員看到。當然，還可以配合着升級套路：升級version（版本）號、換bundle id，換開發者賬號再提交審覈。
如果以上步驟不奏效，還可以嘗試採用修改應用價格、發佈地區、產品分類等方式。不過注意，App上架後價格、發佈地區是可以修改的，但產品分類不可以，對這個有要求的慎用！
IPv6的話，確認代碼沒問題的話，重新提交1~2次就好了。多數是審覈人員所在的網絡環境導致的問題，如果不放心，重新提交時將截圖或拍下視頻放附件裏或直接向蘋果申訴。如果 App本身有問題，例如不兼容 IPv6，最好的辦法是讓App兼容 IPv6 或通過升級服務器來支持IPv6，其他代碼問題問問技術就OK了。
二、2018年App Store算法重大調整首次曝光
2月末，App Store算法進行了一次重大調整：很多產品並沒有優化排名或更新版本等，但關鍵詞數據卻出現了明顯波動（增多或減少）。羣裏很多小夥伴應該都有感知。
該現象集中出現在2月22日，而通過數據分析對比發現，其波動範圍非常廣，中國區App Store的大批量關鍵詞覆蓋與排名數據都受到了不同程度的影響。
七麥研究院曾對2月22日的所有分類榜31000餘款App作爲樣本進行對比，發現和2月21日相比關鍵詞覆蓋數變化率佔比在82.41%以上。其中，關鍵詞覆蓋數增加的數量比例達60.82%，減少比例爲21.59%。
②主要曝光和獲量區間（Top10和Top3）的關鍵詞數量也有較明顯提升,其中，Top10關鍵詞數量增加的達7701款，佔比22.60%，減少App爲8389款，佔比24.62%；Top3關鍵詞數量增加的達6066款，佔比17.80%；減少的App數量爲5154款，佔比15.12%。
目前該現象還沒有明顯恢復，且仍有不斷調整的跡象。截至當前，此次算法調整有哪些趨勢呢？我們應該重點關注哪些因素呢？下面談談我的看法。
1、公司開發者賬號成爲影響App權重的一大因素
針對上述31000餘款app的種類以及關鍵詞覆蓋數變動對比，發現：本次調整中，公司開發者賬號下的App關鍵詞覆蓋與排名增加得更多；而個人開發者賬號相比較而言，關鍵詞覆蓋與排名受到的負面影響更多。在算法變動中，公司開發者賬號成爲了影響App權重的一大因素，並間接對排名優化產生影響。
將樣本App以公司開發者賬號和個人開發者賬號（34000餘款樣本中，公司開發者賬號有16266款，佔比 47.73%；個人開發者賬號有 17811 款，佔比 52.27%）進行區分後，分別從“所有關鍵詞”、“Top10關鍵詞”、“Top3關鍵詞”三個維度進行了對比分析。其中，
① 從關鍵詞總數上來看：如下圖所示，相比2月21日，關鍵詞總覆蓋數減少區間內，個人開發者賬號下的App數量明顯比公司開發者賬號下的App數量多，關鍵詞覆蓋總數減少超過11的App中，個人開發者賬號下的App所佔比例更大。
②從Top3和Top10關鍵詞總數上來看：如果大家覺得上圖對比不太明顯，可以看下方Top3和Top10關鍵詞覆蓋總數變動詳情圖。減少區間（-1以下）中，個人賬號下的App數量和公司賬號下的App數量對比，相差很懸殊。
A、從Top3關鍵詞總數上來看：
關鍵詞增加數量大於11的App中，公司開發者賬號下的App數量高於個人開發者賬號下的App數量；且關鍵詞增加數量在0以下，即關鍵詞減少區間在1~100之間的App中，個人開發者賬號下的App佔比較大。如下圖所示
關鍵詞增加數量在11以上的App中，公司開發者賬號下的App數量同樣多於個人開發者賬號下的App數量；而關鍵詞減少數量在1~100之間的App中，個人開發者賬號下的App佔比也非常大。如下圖所示
2、下載量在算法中仍佔重要比重
此外，我們還從“進入總榜”和“不在總榜但進入分類榜”兩個維度對樣本App進行了數據分析，通過計算兩類App在不同漲幅區間中的佔比發現：App的榜單排名在此次調整中是不可忽略的因素。
例如，在覆蓋總量變化的幾個區間中，僅進入分類榜的App關鍵詞覆蓋數降低、不變、少量增加（1~10）的比例更多；而總榜App關鍵詞覆蓋總量增加超過10以上的App比例呈逐漸增多趨勢。
除此之外，Top 10/Top 3 關鍵詞覆蓋數變化的幾個區間中，總榜所受到的正面影響也優於分類榜。
衆所周知，下載量、評論、日活、留存等是影響App榜單排名的重要因素，而下載量是主要因素。此次榜單排名更好的App受到正面影響更大，其實可以證明，App下載量，或者說自然新增多的產品在此次算法調整中受到的正向影響較多，下載量在此次算法調整中佔重要比重。
3、評論優化權重有所增加
在數據統計和分析過程中發現，本次調整中很多處於相同維度的App，評論優化較好的產品，關鍵詞數量和排名增加的現象更明顯。
下面舉一個比較明顯的例子，大家可以看一下這款產品的評論和關鍵詞覆蓋數量變動情況。
保持穩定週期性地對產品做一些真實用戶的好評優化，更有利於增加產品權重，且在遇到類似於本次算法調整的時候，產品受到的正向影響的機率會更大，負向影響的機率會更小。
4、蘋果對量級（CPSA）的考察時間變長，投放效果延遲
近期關鍵詞排名優化效果出現了延遲現象，12小時候內出現效果的比率降低。很多App優化效果出現在投放後第二天或第三天，有些延遲時間甚至更長！
我們根據抽取的樣例進行統計和分析，關鍵詞排名優化後，效果集中出現在20~28小時。
關鍵詞排名優化效果的延遲很可能是蘋果對搜索下載量的考察時間增長，針對目前的調整，建議優化某個關鍵詞排名後，觀察時間最好延遲1~2天，然後在根據實際情況調整接下來的優化策略。
例如，
①產品進行ASO優化初期，建議每天少量測試多個關鍵詞，縮短關鍵詞投放測試周期，延長關鍵詞優化後的觀察時間，重點關鍵詞延長測試時間至2-3天；
②關鍵詞排名有明顯提升後，再進行下階段的優化，提升關鍵詞排名至目標排名；
③排名提升不明顯的關鍵詞暫時放棄，或隔段時間再進行測試投放。
最後還有4.3問題解決方案
基礎知識：
1.蘋果的審覈，分爲機器審覈和人工審覈；
目前大多數4.3是死在機器審覈階段。
2.蘋果對開發者帳號會進行權重管理；
權重越低的帳號，審覈越嚴格；
同樣的包，可能在權重高的帳號上就能過，在權重低的帳號上就是4.3；
3.目前蘋果還只是對新提交應用進行相似應用的檢測（包括新包和升級包）；
對新包的檢測嚴厲程度和升級包相仿（還是看帳號權重）
預判，隨後會對之前已上架的包也進行相似應用檢測，只是時間的早晚；
規避4.3的重心：
切斷當前馬甲包與以往馬甲包的所有相似性關聯；
相似性關聯包括：
1. ipa包特徵；
2. 開發者帳號；
3. 打包電腦；
4. 上傳IP；
5. 材料相似；
分項細述：
1. ipa包特徵：
包括有代碼相似性，資源相似性；
代碼相似性解決辦法：
a. 已有代碼的混淆（改類名、改函數名）
b. 添加一些無用的代碼；
資源相似性解決辦法：
a. 資源改名；
b. 適當添加一些無用的資源；
2. 開發者帳號：
兩個馬甲包不要關聯到同一個開發者帳號的信息；比如打包時關聯。
3. 打包電腦：
有條件的最好用不同的MAC來打包（每臺MAC上最好打包馬甲包不要超過5個）
4. 上傳IP：
上傳馬甲包時，IP不要跟其他馬甲包的IP相同；
5. 材料相似：
itu後臺材料如宣傳圖，ICON，版權人不要出現相同；
【注：即使是前邊沒審覈過的包，也不要跟他們有關聯。尤其是前邊被4.3拒絕的包，更不能跟他們有相似性】
----------
以上的能做到，基本大部分馬甲可以順利通過4.3這道坎了。更高級的技巧，待後續整理。
----------
補充 關於被拒大禮包問題，就是一個字懟，不能慫。慫了賬號也就廢了 與其這樣不如放手一搏。
歡迎加入ios馬甲包經驗交流羣，羣聊號碼：744520623