Release 6.6.2 - 2023 May

1.0 Campaign Manager module changes and enhancements

1.1 Login URL standardized to webexcampaign (i.e. imicampaign URL will no longer work)

With this release, we are standardizing the login URLs to the ‘webexcampaign’ domain. Most clients are already using this new URL. If you are already using the ‘webexcampaign’ URL, then you need to take no further action.

However, if you were using the ‘imicampaign’ URL, then you should switch to using one of the ‘webexcampaign’ URLs shown in the table below (depending on the region where your account is hosted) – provided that you are not using MMS channel to send out marketing campaigns.

Special consideration for clients using MMS channel campaigns:
If you use MMS channel campaigns, then please continue to use the ‘imicampaign’ URL for now. The reason for this advice is as follows: For the ‘MMS Deployment Previews’ feature to work correctly, (including images and other MMS media) the logged-in user’s domain must match with the ‘default’ domain as specified in the backend database configuration. As we were simultaneously supporting both the old UI and new UI until recently, the ‘default backend’ domain still remains ‘imicampaign’ for many clients. We plan to gradually migrate clients over to the default domain of ‘webexcampaign’ over the next few weeks. You will be contacted by your IMI/Cisco representative to advise when you should switch to using the appropriate ‘webexcampaign’ login URL.

1.2 Advance notice: Upcoming deprecation of v2 APIs from release 6.8 ( ~ Aug/Sept 2023)

We will be deprecating the v2 of all our APIs along with the upcoming release 6.8 which is penciled in to go -live around August/Sept 2023.

After release 6.8, your existing integrations will continue to work for a few more months; however, after release 6.8 goes live, we will not be able to support any investigations into issues that may occur with regards to your applications which use the v2 APIs.

If you have any existing system integrations which might be using the Webex Campaign v2 APIs, then we encourage you to please initiate work with your IT teams to make the necessary changes to upgrade those integrations to using v3 APIs.

More info about the v3 APIs can be found here: https://docs.webexcampaign.com/reference/apis-overview .

An example URL for a v2 API is shown below:

https://CLIENTNAME.imicampaign.io/campaign/event-listener/resources/EventResource/v2/addEvents
i.e., the ‘v2’ label will be seen within the API endpoint.

If you have any questions or concerns about this transition, please contact your IMI/Cisco representative.

2.0 Email Composer module enhancements

2.1 ‘Social Follow block’: Ability to specify ‘alt-text’ for icons within this block

You can now specify the ‘Alt-text’ associated with icons used within the ‘Social Follow’ block.
This enhancement is important to improve the accessibility of your emails designed within the Email Composer for your visually impaired customers (WCAG - Web Content Accessibility Guidelines compliance).

Previously, the ‘Alt-text’ value used to be automatically populated based on the ‘social network’ value selected in the dropdown next to the icons. So if you had some other icons and links (e.g. your own logo and a link to your own website) instead of one of the listed social networks, then the alt-text would not match with those icons and links. As screen-reader software reads out the ‘Alt-text’ HTML tag value for an image, this was causing confusion for visually impaired email recipients.

With this enhancement, we have added a new column of values where you can specify a short ‘alt-text’ value for each icon used within the ‘Social follow’ block.

This feature is associated with the client-suggested Nolt enhancement idea #330.

Usage notes:

1. As part of this enhancement, we have added a value called ‘Other’ in the dropdown in column 2 as shown above.
2. You can specify your preferred ‘Alt-text’ in column 3.
3. If you select one of the well-known social networks (e.g. YouTube , Twitter, Instagram etc.) from the column 2 dropdown, then initially Email Composer will auto-populate the ‘Alt-text’ in column 3 with just the name of that social network (e.g. ‘YouTube’ in the example shown in the above screenshot).
4. If you want to provide a link to a website that is not a social network already listed in the column 2 dropdown, then you should select ‘Other’ from the column 2 dropdown. (e.g. ‘Amazon’ in the example shown in the above screenshot).
5. Even if you select one of the well-known social networks listed in column 2, but you want to specify your own ‘Alt-text’, then you should select the value ‘Other’ from the column 2 dropdown (e.g. ‘Twitter’ and ‘Facebook’ in the above screenshot).
6. Currently the maximum allowed length of the ‘Alt-text’ field in column 3 is 25 characters.

3.0 Dashboard & Reports module enhancements

3.1 Dashboard: App Push Deployments : Customer-level vs Device-level metrics

For App Push channel deployments, we have added some explanatory words on the following 4 screens to clarify that all the ‘Deliverability counts’ shown on the left-side are ‘at customer level’ and all the ‘Engagement counts’ shown on the right-side are ‘at device level’.

1. Dashboard : Campaign details (App channel tab) – Chart view
2. Dashboard : Campaign details (App channel tab) – Table view
3. Dashboard : App push deployment details – Chart view
4. Dashboard : App push deployment details – Table view

This enhancement is associated with ServiceNow tickets PRB0049259 / INC13431342.

Why we have introduced this enhancement:
When sending out App Push deployments, there are 2 ways to target your outbound messages :

a) App push targeting at customer level: This requires you to use your own predefined unique customer ID values in the Target Group (TG) associated with an App push deployment. Some customers could have your app installed on multiple devices. In this case, when the deployment is activated, the app push message will be delivered to all the app instances for those customers on those multiple devices.

In other words, you will be targeting your message to the customer and not to a specific device where your app is installed, e.g., your TG may have 100 customer records. Out of these, 20 customers may have installed your app on their mobile phones and also on their iPad tablets. This deployment will deliver the app push message to 120 devices.

On the Dashboard ‘Deliverability’ left-side panel, the ‘Delivered’ count will be shown as ‘100’ as this count is ‘at customer level’. On the ‘Engagement’ right-side panel, the ‘Delivered’ count will be shown as ‘120’ as this count is ‘at device level’. Please note in this example we have ignored the ‘Assumed delivery’ count in both cases. For more info about the ‘Assumed delivery’ metric, please refer to the following help content page: https://docs.webexcampaign.com/docs/deliverability-and-engagement-metrics-for-app-push

b) App push targeting at device level: This requires you to use the ‘App-device-ID’ values in the Target Group (TG) associated with an App push deployment. These values are very long (over 100 chars alphanumeric) unique IDs assigned by Apple iOS or Google Android when your app is installed on a device. In this case, when the deployment is activated, the app push message will be delivered only to the specific app instances on the specific devices whose ‘App-device-ID’ was listed in your TG file.

In other words, you will be targeting your message to the specific app installed on a specific device and not to a customer, e.g., your TG may have 100 App-device-ID values. This may correspond to 85 customers because 15 out of those 100 App-device-ID values maybe for apps which were installed by 15 customers on their respective second devices.

On the Dashboard ‘Deliverability’ left-side panel, the ‘Delivered’ count will be shown as ‘85’ as this count is ‘at customer level’. On the ‘Engagement’ right-side panel, the ‘Delivered’ count will be shown as ‘100’ as this count is ‘at device level’. Please note in this example we have ignored the ‘Assumed delivery’ count in both cases. For more info about the ‘Assumed delivery’ metric, please refer to the following help content page: https://docs.webexcampaign.com/docs/deliverability-and-engagement-metrics-for-app-push

Screenshots shown below highlight the changes we have made on the 4 screens mentioned above.

1. Dashboard : Campaign details (App channel tab) – Chart view

2. Dashboard : Campaign details (App channel tab) – Table view
   We have added a line for ‘Assumed delivered’ count on the right-side ‘Engagement’ table.

3. Dashboard : App push deployment details – Chart view

4. App push deployment details – Table view
   We have added a line for ‘Assumed delivered’ count on the right-side ‘Engagement’ table.

3.2 Dashboard: 8 new email engagement metrics (BETA)

As mentioned in the release note of the previous release 6.6, you can now optionally request the following 8 additional email engagement metrics to be shown on your dashboard email deployment details page . These will be initially in BETA status.

1. Opens inferred from link clicks (Apple device)
2. % Opens inferred from link clicks (Apple device)
3. Opens inferred from link clicks (non-Apple device)
4. % Opens inferred from link clicks (non-Apple device)
5. Rejected opens due to Apple MPP bots.
6. % Rejected opens due to Apple MPP bots
7. Rejected opens due to non-Apple bots.
8. % Rejected opens due to non-Apple bots

Please contact your Cisco/IMI representative to let them know whether you want these 8 new metrics displayed. Once you have informed them, it may take up to 10 working days for these metrics to be enabled for you.

Usage notes:

1. The existing 4 email engagement metrics remain unchanged in how they are calculated (i.e., unique opens, open rates, unique clicks and CTR).

2. The 8 new email engagement metrics will not be switched on by default for any client; if you are interested in getting these enabled, then please contact your Cisco / IMI account team.

3. The 8 new email engagement metrics will be available on the following 2 Dashboard screens:
   a. Campaign details (Email tab)
   b. Email deployment details

4. To support the reporting and calculation of these future 8 new email engagement metrics, we have introduced within this release 6.6, some new ‘record-types’ in our RTE (Real-time EDR) database. This database is used to keep track of every delivery and engagement event for every customer to whom any message is sent from Webex Campaign on any channel. These new record-types are: 523, 524, 526, 527.

5. The following table provides more info about the above new RTE record-types:

6. If you currently receive a ‘raw’ data-feed from Webex Campaign’s RTE database, then you will have noticed records corresponding to the above new record-types in your data-feed after release 6.6 went live.

7. On the other hand, if you receive a customized data-feed, then it will remain unchanged. If you want these new RTE records to be included within your customized data-feed, then please contact your Cisco/IMI representative; they will need to arrange our professional services team to make this change to the algorithm that generates your custom data-feed.

Background context for the introduction of these new 8 email engagement metrics:

As you may recall, Apple introduced the MPP (Mail Privacy Protection) feature in iOS, iPadOS and MacOS in Sept – Oct 2021. For customers using the Apple Mail app and who opt-in for this MPP feature on their Apple devices (iPhones, iPads and Mac computers), Apple will first retrieve all their emails into its own proxy server. If and when the customer actually attempts to view their email, it will be served from Apple’s MPP servers and not from the original sender.

While Apple’s intentions may have been good (i.e., to better protect the privacy of the customers of its devices), this MPP feature does have the following unintended consequences for email marketers:
• The ‘email open’ action cannot now reliably be tracked for Apple customers who opted into the MPP feature because the industry-standard method of tracking email opens relies on an invisible transparent ‘tracking pixel’ image which is served from the email sender’s servers. As Apple’s ‘MPP bots’ are now retrieving all emails for MPP-opted-in customers, it is now harder to decide whether and when such a customer has actually opened their emails.
• If there is any logic in place to decide whether to send a ‘follow-up message’ based on tracking of the ‘previous-email-opened-or-not’ event, then this logic will now be less reliable for the subset of your customer base who may have opted into Apple’s MPP feature.

In this release, we have added the capability to ‘infer’ email opens if Webex Campaign detects that a link has been clicked within an email – even if it was not possible to reliably detect the email-open itself for a customer because they had opted into the Apple MPP feature.

This is represented by the first 4 new metrics listed above:
• Opens inferred from link clicks (Apple device)
• % Opens inferred from link clicks (Apple device) ; this % is derived by dividing by the ‘delivered’ count
• Opens inferred from link clicks (non-Apple device)
• % Opens inferred from link clicks (non-Apple device) ; this % is derived by dividing by the ‘delivered’ count

Even before Apple’s introduction of the MPP feature within its own ecosystem, there have been similar other bot-systems operational within other internet ecosystems; however, considering Apple’s large share of the devices market in the USA, Europe and many other regions, the Apple MPP feature has had more of an impact on email marketing ‘email opened’ metrics since its introduction in late 2021.

That’s why we had implemented many years ago the capability within Webex Campaign to filter out email opens that could reasonably be attributed to some type of ‘bot activity’. After Apple’s introduction of the MPP feature in late 2021, the email-opens that were attributed to Apple’s ‘MPP bot’, also automatically began to be filtered out within Webex Campaign’s email open metrics due to our already existing filtering algorithms.

With the introduction of these new email engagement metrics in the next release, we will be introducing more transparency in this already-existing filtering process.

This is represented by the last 4 metrics new metrics listed above:

• Rejected opens due to Apple MPP bots.
• % Rejected opens due to Apple MPP bots ; this % is derived by dividing by the ‘delivered’ count
• Rejected opens due to non-Apple bots.
• % Rejected opens due to non-Apple bots; this % is derived by dividing by the ‘delivered’ count

4.0 Maintenance items in this release

The table below lists smaller improvements and bug-fixes that are included in this release.

5.0 Need more information?

• Please contact your Cisco / imimobile client representative if you have questions or would like access to a new feature.
• Cisco Webex technical support team can be contacted at any time by phone or email:

• Europe / Middle East / Africa:
  • Phone: +44 (0) 1494 750 600
  • Email: [email protected]
• North America:
  • Phone: +1-855-324-0970
  • Email: [email protected]