App 邀請機制是每個產品幾乎必做的功能點，它一般以兩種形式存在：一是作為常置功能用於推薦，二是作為裂變活動用於邀請。
無論以哪種形式出現，都可以歸為社交分享的一種表現方式。相較於營銷推廣，邀請好友機制顯然獲客的預算成本低得多。另外，邀請的優點不僅在於引流新用戶，在邀請時無形中也增強了老用戶對產品的認同感和活躍度。簡單來說，這是產品低成本拉新促活的不二之選。
但實際在使用邀請碼機制拉新過程中，效果依然不明顯，是產品自身問題呢？用戶不願意安裝？還是哪個環節出現問題呢？
大家是否考慮過在邀請環節里出現用戶流失的情況呢？
下面先介紹填寫邀請碼與免邀請碼優勢與劣勢。
一、傳統填寫邀請碼
原理非常簡單：邀請人生成一個專屬的邀請碼給到被邀請人（新用戶）填寫即可。
而填寫邀請碼環節的出現，本質上是滿足開發者和推廣人員的統計需求，卻沒有考慮用戶的體驗，反而在安裝過程增加一個填寫環節，增加了潛在用戶流失的可能（操作流程越復雜，用戶的流失率就越高）。一旦老用戶認為獎勵的意義不大，新用戶又對“填寫邀請碼”環節的繁瑣產生了反感，選擇“放棄注冊”或者“跳過邀請碼”，邀請注冊活動就會以失敗告終。
為什么用戶會在填寫邀請碼環節戛然而止呢？
主要原因是：邀請碼是由人工操作填寫，大多數用戶會在這一步里失去耐心。而填寫邀請碼本質是為了滿足開發和推廣人員的統計需求，我們為什么不能去掉用戶填寫邀請碼碼的步驟呢？使用程序自動填寫，同時也可以滿足開發和推廣人員的統計需求呢？
下面就介紹基於傳統填寫邀請碼優化出來的方案。
二、免填邀請碼
事實上國內已有好幾家服務商提出解決方案了。例如：openinstall、sharetrace …，這里就不逐一介紹了，實現的原理基本一致。
就拿sharetrace來說實現的原理吧：
開發者在分享的H5頁面上集成sharetrace的web sdk，發布分享鏈接時會在url后面拼接需要的參數（邀請碼、渠道號等），例如：A用戶的URL后面帶的參數可能是code=A，B用戶分的URL參數就是code=B。
當終端訪問這個分享的H5頁面時，openinstall的web sdk 會上傳這個終端的設備信息和url拼接的參數，上傳到服務器進行判斷，再使用sdk從第三方服務器再取回暫存的自定義參數。
開發者根據各自的需求，在分享鏈接自定義各種動態參數。比如通過在分享鏈接url中附帶App邀請人的用戶id，就可達到免填邀請碼的效果。
根據這種原理，可以實現精准識別每個安裝來源。可以不填邀請碼又可以滿足開發和推廣人員的統計需求。
三、結語
說到這里，相信大家已經了解傳統填寫邀請碼與免邀請碼的區別吧。
可以說免邀請碼方案更合適現階段的推廣手段，同時這項技術自然也可以應用到無數領域中，只要有渠道來源監測或識別的需求，都可以滿足。
該文章我也發布到了CSDN: 地址