傳統邀請碼安裝與免邀請碼安裝區別,如何選擇呢?

App 邀請機制是每個產品幾乎必做的功能點,它一般以兩種形式存在:一是作為常置功能用於推薦,二是作為裂變活動用於邀請。

無論以哪種形式出現,都可以歸為社交分享的一種表現方式。相較於營銷推廣,邀請好友機制顯然獲客的預算成本低得多。另外,邀請的優點不僅在於引流新使用者,在邀請時無形中也增強了老使用者對產品的認同感和活躍度。簡單來說,這是產品低成本拉新促活的不二之選。

但實際在使用邀請碼機制拉新過程中,效果依然不明顯,是產品自身問題呢?使用者不願意安裝?還是哪個環節出現問題呢?

大家是否考慮過在邀請環節裡出現使用者流失的情況呢?

下面先介紹填寫邀請碼與免邀請碼優勢與劣勢。

一、傳統填寫邀請碼

原理非常簡單:邀請人生成一個專屬的邀請碼給到被邀請人(新使用者)填寫即可。

傳統邀請碼安裝與免邀請碼安裝區別,如何選擇呢?

而填寫邀請碼環節的出現,本質上是滿足開發者和推廣人員的統計需求,卻沒有考慮使用者的體驗,反而在安裝過程增加一個填寫環節,增加了潛在使用者流失的可能(操作流程越複雜,使用者的流失率就越高)。一旦老使用者認為獎勵的意義不大,新使用者又對“填寫邀請碼”環節的繁瑣產生了反感,選擇“放棄註冊”或者“跳過邀請碼”,邀請註冊活動就會以失敗告終。

為什麼使用者會在填寫邀請碼環節戛然而止呢?

主要原因是:邀請碼是由人工操作填寫,大多數使用者會在這一步裡失去耐心。而填寫邀請碼本質是為了滿足開發和推廣人員的統計需求,我們為什麼不能去掉使用者填寫邀請碼碼的步驟呢?使用程式自動填寫,同時也可以滿足開發和推廣人員的統計需求呢?

傳統邀請碼安裝與免邀請碼安裝區別,如何選擇呢?

下面就介紹基於傳統填寫邀請碼優化出來的方案。

二、免填邀請碼

事實上國內已有好幾家服務商提出解決方案了。例如:openinstall、shareinstall、sharetrace …,這裡就不逐一介紹了,實現的原理基本一致。

就拿openinstall來說實現的原理吧:

開發者在分享的H5頁面上整合openinstall的web sdk,釋出分享連結時會在url後面拼接需要的引數(邀請碼、渠道號等),例如:A使用者的URL後面帶的引數可能是code=A,B使用者分的URL引數就是code=B。

當終端訪問這個分享的H5頁面時,openinstall的web sdk 會上傳這個終端的裝置資訊和url拼接的引數,上傳到伺服器進行判斷,再使用sdk從第三方伺服器再取回暫存的自定義引數。

開發者根據各自的需求,在分享連結自定義各種動態引數。比如透過在分享連結url中附帶App邀請人的使用者id,就可達到免填邀請碼的效果。

傳統邀請碼安裝與免邀請碼安裝區別,如何選擇呢?

根據這種原理,可以實現精準識別每個安裝來源。可以不填邀請碼又可以滿足開發和推廣人員的統計需求。

三、結語

說到這裡,相信大家已經瞭解傳統填寫邀請碼與免邀請碼的區別吧。

可以說免邀請碼方案更合適現階段的推廣手段,同時這項技術自然也可以應用到無數領域中,只要有渠道來源監測或識別的需求,都可以滿足。

頂部