Future-Proofing Your SAS CI360 Mobile Setup (So You’re Not Stuck in an Endless Update Cycle)

[#1]

Hey there! Let’s talk about SAS CI360’s mobile capabilities—specifically, how to set things up so you don’t end up constantly begging your dev team for app updates every time marketing has a new idea.

Most people start with just one use case in mind. Like, “Let’s send Push Notifications to get users back into the app!”—whether that’s for promoting a shiny new product or nudging them to please, for the love of all things e-commerce, finish their abandoned cart.

And that’s great! You set up push notifications, implement the Custom Event in the SAS CI360 Mobile SDK, test it, release it… and boom, it works!

Here is an example. You create the Event configuration in SAS CI360 user interface. Let us call it "New-SIM-Application-Submit" event.

Then you ask your mobile app developer to use the SAS CI30 Mobile SDK to send in a Custom Event with the same Event Name. It may look something like this.

SASCollectorEvent event = new SASCollectorEvent();

HashMap<String, String> myEventAttributeMap = new HashMap<>();
myEventAttributeMap.put("sim_plan_name", "data card sim");

event.setEventKey("New-SIM-Application-Submit");
event.setAttributes(myEventAttributeMap);

SASCollector.getInstance().addAppEvent(event);

And everything works just fine...

But then…

• Marketing wants to track people submitting applications for a new SIM card.
• Oh, now they also want to track people applying for broadband.
• Wait, now we need to track service requests too?

Each time, you go back to your dev team, update the app, and wait for Google and Apple to take their sweet time approving the release. Meanwhile, users may or may not ever update their apps, meaning your fancy new tracking doesn’t even work for half of them.

This can get frustrating real fast. So let’s talk about a better way.

The Smarter Way: Stop Hardcoding Everything

Instead of creating new events for every single thing, we can future-proof the setup by using one flexible event that handles multiple use cases.

Step 1: Create a Generic Event

Instead of setting up "New-SIM-Application-Submit", "New-Broadband-Application-Submit", and "Service-Request-Submit", let’s just create one event called… I don’t know, maybe "mobile_app_button_click".

Step 2: Add Attributes to Make It Smart

This is where the magic happens. Instead of baking every little detail into the event name, just pass attributes to explain the event.
For example, in the user interface of SAS CI360, define a generic event that can collect most button click events with a flexible number of attributes.

SASCollectorEvent event = new SASCollectorEvent();
HashMap<String, String> myEventAttributeMap = new HashMap<>();
myEventAttributeMap.put("button_id", "new sim card applciation");
myEventAttributeMap.put("page_title_text", "New SIM Card Applications");
myEventAttributeMap.put("page_url", "/products/sim/new-sim");
myEventAttributeMap.put("button_display_text", "Get the new SIM Now");
//And more generic attributes that you need based on your app and organizational needs.

event.setEventKey("mobile_app_button_click");
event.setAttributes(myEventAttributeMap);

SASCollector.getInstance().addAppEvent(event);

Now, instead of asking developers to push new app updates every time marketing wants to track a new "button click", we just use the generic event with appropriate event attribute conditions.

Why This Saves Everyone’s Sanity

• No more waiting for app store approvals – Because who wants to be at the mercy of Apple and Google?
• Marketing gets more control – No more “Hey dev team, can you add this tiny thing?” every week.
• New use cases go live faster – Like, actually fast. Not “wait three weeks for an app update” fast.

Things to watch out for...

Alright, before you run off and implement this genius generic event approach, there are a few things to keep in mind.

Use Event Attribute Conditions (Or Risk Total Chaos)

When using a generic event as a Trigger or Target, always make sure to use event attribute conditions—otherwise, you might end up targeting the wrong users.
For example, let’s say you want to identify all users who submitted an application for a new SIM card. If you just use the "mobile_app_button_click" event as your trigger without any conditions, you’ll accidentally include broadband applicants, service requests, and whatever else marketing decides to track next. Not ideal.

Instead, make sure to add a condition like this:

This way, you’re only working with the right audience and not bombarding broadband users with irrelevant messages about their non-existent SIM card.

Convenience Matters – Don’t Overdo the Generic Approach

Now, while generic events are super handy, you don’t want to go too generic and make life harder for yourself (or your marketing team). Some features deserve their own dedicated event—especially the ones that are critical to your app’s functionality.

For example, "Add-To-Cart" is a big deal in an e-commerce app. Instead of stuffing it into a generic button-click event, it makes sense to create a dedicated "Add-To-Cart" event with useful attributes like:

• Cart Total (so you know if they added a $10 item or a $10,000 item)
• Product Category (electronics vs. groceries, because a reminder to buy fresh veggies won’t help someone who added an iPhone)
• User Segment (new user vs. repeat customer, to personalize follow-ups)

Having dedicated events for major actions makes reporting way easier and helps marketing fine-tune their strategies without driving the dev team crazy.

Is That All? Nope, Not Even Close!

The button-click event was just the tip of the iceberg! There are plenty of other must-have events that I highly recommend setting up in your first few releases. Trust me, getting these in early will save you a ton of headaches later.
Here are some of my personal favorites (and why you’ll love them too):

1. Login & Logout – Because Identity Matters

Yes, SAS CI360 has its own fancy Identity Attach/Detach events—but here’s the catch: they can’t be used as a trigger or target! They’re mainly for user identification and personalization.
So, what happens if your marketing team wants to send an in-app message promoting an upcoming event right when a user logs in? Well... they can’t. At least, not with the default identity events.
The fix? Send a "Login" and "Logout" event as a custom event in SAS CI360. Just promise me one thing—DO NOT include usernames or passwords in the event. Seriously, don’t. 

2. Page View – The Unsung Hero

A Page View event is a must-have—no debate.
Why? Because tracking which pages a user visits lets you:

• See what’s trending (or totally ignored)
• Personalize experiences based on where users spend time
• Send hyper-relevant follow-ups

Example? Say a user visits your "Loyalty Program" page. You can:

• Trigger a Push Notification nudging them to sign up
• Create a segment of users who visited it 3+ times but didn’t register (clearly, they’re interested but need a little push)
  Powerful, right?

3. Product Views & Cart Actions – Show Me the Money!

Remember when I said some actions deserve dedicated events? This is one of them.
Track these separately:

• Product View – Know what users are checking out
• Add to Cart – So you can remind them when they forget
• Remove from Cart – Maybe they need a better offer?
• Purchase – Because, well… that’s the goal!

Each of these should capture relevant details like product category, price, cart total, and even discounts applied.

4. Search Events – What Are Users Looking For?

Most apps have a search bar—and if yours does, track it!
Why? Because knowing what users are searching for can help with:

• Personalization – Show them more of what they want
• Fixing gaps – If searches return zero results, maybe you need to add those products
• Segmenting users – If someone searches “wireless earbuds” five times, they’re clearly ready to buy

Bonus tip: Track search success vs. failure. If too many users are getting no results, something’s broken.

5. Notification Events – Not Just SAS CI360’s Push Messages

SAS CI360 automatically tracks its own Push & In-App notifications, but let’s be real—you’re probably using other providers too (Adobe, Firebase, Salesforce, etc.).
To get a complete view of user engagement, track ALL notification interactions, including:

• Order delivered notifications from your e-commerce platform
• Bank alerts about transactions or statements
• Promotional messages from third-party systems

Why? Because if you feed this data into CI360, you can build better audiences and unlock new cross-sell/upsell opportunities.

Final Thoughts

Getting your event tracking right from the start will make life so much easier down the line. Use generic events where needed, but don’t be afraid to go dedicated when it makes sense.
Have any epic event-tracking fails or brilliant hacks? Drop them in the comments—I’d love to hear them!

Breaking tech, not spirits—one post at a time!

 

References:

• AS Customer Intelligence 360: Developer’s Guide for Mobile Applications: https://go.documentation.sas.com/doc/en/cintcdc/production.a/cintmobdg/titlepage.htm
• From the video portal: https://video.sas.com/category/videos/sas-customer-intelligence-360-mobile-sdk
• From Learn: https://learn.sas.com/course/view.php?id=6732