Web Push Notifications are clickable messages sent to the browsers of users' devices – mobile, tablet, and desktop. The notifications will be sent only to the users who have subscribed for the notifications. Once a user subscribes for the web push, he will start receiving the notifications. It's not necessary for users to be on the website to receive web push. The core proposition of web push notifications is to bring back users to the website.
When a user visits your website, he receives an opt-in notification requesting his permission to send him notifications in future. When he clicks 'Allow', he is added to the list, and at the backend, the browser id gets automatically captured.
Once the visitor becomes a subscriber, you can start pushing him web push notifications based on the browser id. When web push notification is served to the user, who is in or out of your website, sees the notification, clicks on it, and is redirected to the landing page.
Currently, web push notification technology supports all major browsers such as Chrome, Mozilla Firefox, Opera, and Safari, which have around 80% of internet users.
No, web push notifications don't work in incognito mode.
Cookies last for a maximum lifetime. When a web server sends a cookie, it asks your browser to keep that particular cookie till lifetime, so that website visitor won't get web push subscription popup again and won't be distracted.
Chromev61 update will affect only websites in HTTP protocol and not the HTTPS websites. As per latest update shared by Google, HTTP Websites will not be able to display the default browser subscription box directly without the permission of the user. So the custom subscription request have to be displayed first and once the users clicks on the allow button, the default box will be displayed and the regular subscription process follows. iCubesPro Browser push notification subscriptions already follows the above mentioned approach for all HTTP websites, and our customers will not be affected by the mentioned update.
We can do in 3 different ways.
The system will take image and description (Name, Price etc..) from the Google Product Feed.
Yes. It should be rss2.0 UTF 8 encoded format in xml according to scores assigned on each activity
There is no limit in the no of product recommendations. We can display products according to HTML size.
Yes. Very much possible.
Simplest way to grow your subscriber list organically in real-time. Provide your website visitors an ineluctable offer (Offering a special deal in exchange for an email address)through an HTML or image popup, when the website is fully loaded or when the visitor is detected about to leave the website.
Android, Mac, Ubuntu,Windows, Linux, iPhone.
Yes, cMecury List Builder works on Incgnito mode.
We have to insert single Java script code in the admin panel of the website. Once the code is inserted in the web site , we can create 'n' number of pop ups in multiple pages.
No, there is no custom coding required for implementing different pop ups in multiple pages. But the domain used for creating Java script and the domain used for creating other pop ups should be same.
There is no precise audience. We can serve pop ups to the complete organic users who are coming to the website.
In simpler terms Email deliverability refers to delivering the mails directly to the inbox as intended rather than delivering them to Spam/Junk folder (Deliverability failure).
The major types of Bounces are soft bounces and hard bounces.
Email bounces are treated as hard when the addresses are,
Hard bounces can be reduced using the following methods.
Soft bounces occur when a recipient is not available or the mail is getting blocked at the recipient's end. The mailbox provider or ISP will return a bounce code back to the sender. Soft bounces are a usually indicator of message content quality and relevance.
Normally Soft bounces occurs for,
Major reasons people may complain about your messages are:
The Spam complaint rate can be reduced by,
In simpler words, SPF or Sender Policy Framework is a security mechanism created to prevent someone from sending mails in your name. The Mechanism is all about the communication between DNS Servers.
Through SPF, a domain may explicitly authorize the hosts that are allowed to use its domain name. SPF works by publishing DNS resource records that declare which hosts are allowed to use a domain name. The receiving mail server checks the SPF records from the domain identified as sending the email to verify that the source IP which the email originated from is authorized to send email from that domain.
An SPF record is of the form:
v=spf1 +mx a:xog.example.com/28 ~all
Each qualifier has its own meaning.
Domain Keys Identified Mail (DKIM) standard has been created for the same reason as SPF: to prevent the bad guys from impersonating you as an email sender. It's a way to additionally sign your emails in a way that will allow the recipient's server check if the sender was really you or not.
With DKIM, a signer can cryptographically sign an email message for a domain, claiming responsibility for its authenticity. The recipient verifies the signature by querying the signing domain for the public key to confirm that the signature was encrypted by the appropriate private key. DKIM-Signatures are generated by code which the signer adds to the appropriate agent.
The whole idea is based on encrypting and decrypting the additional signature, put in the header of your message. To make that possible, you need to have two keys:
We partner strictly with the Industry best technology partners with a proven track record, ensuring a direct relationship with the leading network operators and trusted local partners helping our customers to deliver messages glitch free."