Native Opt-in
Native opt-ins are triggered when the browser displays the prompt to seek permission from the user without any context. There is no additional information as to why a user should opt-in. Native opt-in can only be enabled on HTTPS certified websites.
The text on this type of opt-in is non-customizable because it is decided by the browser and varies based on the browser, OS you use, and localization. There are 3 action buttons to this opt-in: Allow, Block, and Close.
Native Opt-in is the winner. Reasons why native opt-ins are better:
- Native Opt-ins seem more trustworthy and users have gotten used to it by seeing it on multiple websites.
- Unlike custom opt-ins, native opt-ins are very simple and clear. Custom opt-ins may sometimes come across cluttered.
- Users today are concerned about their security, privacy, and how their data is being handled. They usually refrain from HTTP websites. If your website is not HTTPS certified and uses custom opt-ins then it gives users one more reason to not trust you with their information.
Getting your web users’ opt-in is the key to long-term success for your engagement and retention strategy. “Acquisition” might be your initial priority for growth but you need to focus more on engaging your existing users.
Experimenting between triggering it by default vs having a notification bell icon (User Driven): You can always experiment with the timing of the native opt-in as to when the user should see the prompt (Immediately or delayed). And you can also give users onsite customization with a bell icon and when clicked upon the user will see an opt-in prompt.
