Azure Notification Hubs provides a highly scalable, cross-platform push notification infrastructure that enables you to either broadcast push notifications to millions of users at once, or tailor notifications to individual users. You can use Notification Hubs with any connected mobile application—whether it’s built on Azure Virtual Machines, Cloud Services, Web Sites, or Mobile Services.
Pricing Details
Free | Basic | Standard | |
---|---|---|---|
Basic charge
1
Included pushes |
Free
1 million 2 |
¥46.16 / month
10 million |
¥923.41 / month
10 million |
Additional pushes
10 million-100 million/month Over 100 million/month |
N/A N/A |
¥4.61 / million ¥4.61 / million |
¥46.16 / million ¥11.54/million |
Number of active devices | Unlimited | Unlimited | Unlimited |
Basic-type x-plat push to individual devices | √ | √ | √ |
Broadcast (label size) | Limit: 10K | Limit: 10K | Unlimited |
Label number (broadcasting group) | Limit: 3K | Limit: 3K | Unlimited |
Automatic scaling | √ | √ | |
Queryable audience (registration queries) | √ | ||
Scheduled push | √ | ||
Telemetry | √ | ||
Bulk import | √ | ||
Multi-tenancy | √ |
FAQ
Expand all-
What is Azure Notification Hubs Baidu Cloud Messaging?
For application program developers, it is challenging to develop Android application programs aimed at the Chinese market that can receive pushed notifications. Android mobile phones usually do not have Google Play. However, these devices can only receive notifications from GCM (Google Cloud Messaging) through Google Play. Meanwhile, many different application stores and messaging services make this even more difficult.
Today, we announce support for sending pushes from Azure Notification Hub to these kinds of Android devices through Baidu Cloud Messaging. This is in addition to existing support for iOS, Windows Phone, Windows, Android and Kindle devices in Azure Notification Hub.
Application program developers must log in to Baidu portal, register themselves as Baidu developers, create a cloud messaging project and get the corresponding identifier for an application program (UserId and ChannelId). Then, they should insert the identifier into Azure Notification Hub on the Azure Management Portal. After that, they can use Notification Hub Android SDK updated in their client-side application program to register the device in Notification Hub, and then use updated Service Bus/Notification Hub.NET SDK to push notifications, which will be transmitted to the registered Android device through Baidu Cloud Messaging.
Here is the detailed Tutorial for Beginners about development.
-
What will happen to existing users of Notification Hubs after December 1, 2014?
Subscribers of Notification Hubs registered before December 1, 2014 will be automatically charged at the new pricing of the corresponding service. If a user has been using Basic services before, he will be automatically moved to a new basic class. For more help, please contact Support .
-
How does the Basic layer automatically scale?
Before November 30, 2014, you can designate the minimum value of unit numbers for your Namespace on the Management Portal (to ensure enough capacity is left for active devices or push notifications exceeding the present level). You can also set the maximum unit number that you hope the service bus can use when it automatically scales according to the actual use level of Namespace. At the beginning of each day (00:00 UTC time), we will provide capacity not less than the minimum value set by you or the minimum capacity needed to support your current active devices. During the following whole day, if the number of your active devices or push notifications exceed the currently provided level, we will increase the capacity up to the maximum value chosen by you (before extra capacity is successfully supplied, you may experience throttling or a long delay). At the end of the day (at midnight UTC time), you will be charged by the maximum value of units used in the whole day. If you want to stop the automatic scaling function, you can set the same figure for maximum value and minimum value.
From December 1, 2014 on, Basic and Standard services do not need automatic scaling. Customers can use limitless messaging function at the current published charge rate.
-
Does Notification Hubs have any form of quota?
Before November 30, 2014, free services allowed daily average pushed notifications of 3,333 per day. Basic service was 16,667 per day, a standard unit was 166,667 per day.
After Namespace reached the cap for daily number of pushes and before the end of the day (midnight UTC time), or before more units were chosen in Standard service, or before it was upgraded to Premium service to raise the cap, the Namespace could no longer send notifications.
For Standard services, the number of units can automatically scale.
From December 1, 2014 on,the daily quota of pushes were invalidated due to changes in the cost of Basic expenses and messaging charges.
-
Do free services have any caps for the number of active devices?
Before November 30, 2014, the number of active devices was constantly tracked. When the number of active devices reach the cap, registration operations for new devices would not succeed until the number of active devices fell below the cap (log off of registered devices through expiration operations), or until Standard service was upgraded or extended to raise the cap, or Basic or Standard units were expanded.
From December 1, 2014 on, all service levels have no caps on the number of active devices.
-
What is contained in every push?
The push contains all notifications provided for platform messaging services (e.g., Windows notification service, Apple Messaging Service, Google Cloud Messaging, Microsoft Push Notification Service).
-
What is an active device?
Active devices are devices that can receive notifications. Google Cloud Messaging or Amazon Device Messaging should be used to define a unique registration ID for such devices; or Windows Push Notification Service or Microsoft Push Notification Service should be used to register a URI (Uniform Resource Identifier); or Apple Push Notification Service is used to create device tokens. It is worth noting that a physical device can be regarded as multiple active devices in Notification Hubs.
-
What is Broadcast and Label?
“Broadcast” refers to the number of devices that your push notifications can reach through a notification request. “Label” refers to the keyword subscribed by a device. The push notifications of Broadcast can be sent to all devices that have subscribed to certain labels.
Before November 30, 2014, the Broadcast function limit was the same as the limit of the number of active devices at your Notification Hubs service level.
From December 1, 2014, in terms of Free and Basic services of Notification Hubs, you can send a broadcast to a target audience with at most 10,000 devices. If the audience has more devices than that, 10,000 devices will be chosen at random as receiving devices and the rest of the devices cannot receive any notifications.
-
What is a Namespace? How many units can be used by each Namespace in Basic and Standard service?
Namespace is a grouping mechanism which may contain multiple Notification Hubs. Before November 30, 2014, Azure Management Portal allowed customers to extend each Namespace to at most 50 units in Standard service. If your Namespace needs a larger capacity, please contact Support .
From December 1, 2014, billing will be calculated at the Basic level cost plus the number of pushed notifications, so the unit limit will be canceled.
For other common questions about Notification Hubs, please refer to this MSDN article .
Support & SLA
If you have any questions or need help, please visit Azure Support and select self-help service or any other method to contact us for support.
For the “Basic” and “Standard” levels of Notification Hubs, we guarantee that, at least 99.9% of the time, Notification Hub services operating at Basic or Standard level can successfully send notifications or perform operations about registration management through correctly configured application programs. To learn more about the details of our Service Level Agreement, please visit the Service Level Agreements page.