User's followers should receive push notifications upon a post creation - Correct use of Tags ?

Follow

Hi Sid,

Yes, the approach you've outlined would be the most ideal way to accomplish that use case.

Thanks Michael for the feedback.

Now suppose A logs out from the app and user B logs in on the same device. I don't want user B to get notified of the events that user A subscribed to. How will I achieve this ?

Sid,

For that, you might want to consider adding tags to the Named User.

When you add tags to the device, they stay on the device, no matter what user is logged in or logged out. The device is identified by the Channel ID. So, in this case, you're only ever setting a tag on the Channel Id, which remains on the device even with users logging in and logging out.

Named Users allow you to set an ID on that device that might link to your username, email, profile ID, etc., from your backend for example.

With it, you can also add additional tags to that Named User, such that you can specify a particular Named User tag to target.

I'd recommend taking a look at our Named User documentation, as it will walk you through setting that up as well as setting Tags on those Named Users, so you can accomplish that particular use case.

That was fast!

Ok, so you mean that instead of adding tags to the channel, I should add tags to the named user. And I can send pushes based on namedUser's tags, instead of Channel's tags ?

Sid,

First, you'll want to set your Named User on the device when the user logs in.

To do that, you would do:

UAirship.namedUser().identifier = "NamedUserID"

Once you have a Named User set, then you can add tags to it by doing the following:

UAirship.namedUser().addTags(["Addtag1","AddTag2"], group: "Tag Group ID")

You'll notice two things about the code above. 

One, is that I'm now passing in an array of tags to the addTags method. 

The second, is that an additional parameter is now required. And that is the Tag Group.

Think of a Tag Group like a folder of tags. This feature is available to you to allow you to separate tags that are set on the Channel ID (device) vs. tags set somewhere else (Named Users, external server, CRM database, etc.).

In this case, you'll need to specify a Tag Group to set that Named User on. But, before you do that, you need to Create a Tag Group first. Once you have a Tag Group defined in your dashboard, you can then begin storing your tags in there via the Named User call above.

Great ... thanks for the great explaination. I'll try that.

On a separate note, I observed this:

- Installed the app

- A channel appeared in Go dashboard.

- Deleted the app from device and installed again (all using XCode debug builds)

- I noticed that the channel ID on the Go dashboard did not change.

I'm just curious of about how this is achieved. From what I know, we cannot uniquely identify a device in a reliable way. So how do you achieve this ? My guess is saving previously created channel ID in iOS Keychain.

Sid,

You nailed it!

We save the Channel ID in the keychain such that it persists across installs and uninstalls. This is so that you're able to keep certain tags the same and not trigger certain automation workflows (new user vs. existing) when the user reinstalls the app.

Cool!

1. Is there a limit of adding tags to a namedUser (or channel for that matter) ?

2. Even if there is a provision of having lots of tags, is there a 'recommended' limit so that Fanning out of notifications remains reliable (I've read somewhere that Facebook's 5000 friends limit might have something to do with this scalability issue)

3. I've read that it is recommended to save namedUser tags via the backend because that's more secure. Is there a difference (in terms of plan pricing and limits) between calling an backend to Airship API vs. doing things via SDKs ?

4. What's the point of allowing free-tier users to send 1 million messages per month, when they can only have 1,000 addressable users per month. (I wouldn't send 1,000 messages a month on average to a single user :))

5. For the free tier, what will happen if the limit of addressable user exceeds (or approaching) the limit of 1,000.

6. Consider a new device. When the app calls .takeOff() and registration succeeds, will this be counted as a new 'addressable user' or addressable users are only those marked as namedUsers ?

Sid,

1. There is no hard limit of adding tags to a Named User, however you'll want to keep in mind that you'll need to be able to track and manage those tags at some point in time. So, if a single Named User has over 9000 tags, it could be difficult to keep track of those. For more Best practices about the Urban Airship API, you can read about the Limitations in the Engage API.

2. I'd normally recommend somewhere between 1000-2000 tags per user. 

3. There is no difference in terms of plan pricing or limits when setting Named Users via the API or via the SDK.

4. According to our pricing page, the Starter edition allows for unlimited notifications, with up to 1,000 addressable users. I'm not sure where you got the 1 million messages per month?

5. Should you approach this limit or exceed it, a member of our team will reach out to you via the email listed on your account and talk about next steps. 

6. Yes, that device will be counted as an Addressable User. You can read more about Addressable User in our Addressable Users documentation.

Thanks Mike Halka for all the answers. Here are a couple of questions for today :)

7. I can see the logs/status of the push messages sent via Dashboard but I'm not able to see details of the push messages that were sent via SDKs. What am I missing ?

8. On a separate note, assume that an app uses Analytics to track events like 'profile views' etc. There is also some UI to show profile_view_counts in the mobile app. Is it a good idea use this Urban Analytics data to populate the UI of the end-user app ? Even if it's not a good idea, how do an app read the analytics summary values ?

Sorry for my mistake about 1 million pushes. For free-tier, what's the point of allowing me to send unlimited push message while the addressable user limit is just 1,000 per month ?

7. Push notifications are not sent from the SDK directly. Pushes are generally sent via the API, which you'll be able to view within the Activity Log in the Dashboard. Or, pushes can be sent directly from the Dashboard, which you'll see under the Message Overview page. At no point in time is a push sent directly from the device.

8. I would say this is a good idea, however in order to accomplish something like this, you would need to be able to sort an individuals events. The Engage reporting only shows you app events at an aggregate level, meaning you would not be able to know exactly how many times User A viewed User B's profile. It is all aggregated so you get the total number of app events for your app, not per user.

To get to user level reporting, you would need something like our Connect product. Connect allows you to be able to stream any and all information about your app to an external source, for example an Amazon S3 bucket. From there, you could process the information and find out how many events User A viewed User B's profile and be able to show that in the app in whatever method you choose.

It's a little complex, but not impossible to do. It will require you to have the ability to store this data, be able to process the data, and communicate it to your app in some fashion. It also assumes you're setting those profile view events as a Custom Event in the app already.

For the free-tier, we allow you to send an unlimited number of pushes to your audience. If, however, your app audience grows to more than 1,000 than we can work with you to determine what pricing would look like beyond that initial tier of users. After 1,000, you'll need to move to a paid plan.

Stumbled upon an article that discusses how Apple is working on a fix/change that would delete the keychain data after an app is uninstalled.

https://forums.developer.apple.com/message/210531#210531

Sid,

If you read further down in the thread to the latest response, it appears that this was something that developers experienced on iOS 10.3 beta versions. 

Since the public 10.3 has been released, those developers, nor have we, been able to reproduce that situation.

That said, we will always continue to monitor situations like this and will work with Apple's recommendations accordingly.