Here you can find all my Salesforce IdeaExchange contributions. Let's make the change!
_Job Data View field that stores timestamp for the email delivery (the moment when it successfully reached the target Email Service Provider). It is currently impossible to get delivery time for emails sent via Journey Builder.
It is happening, however, only for Journey Builder emails. Sends via any other methods (for example Send Flow) are correctly displaying the delivery time.
I see it as a massive limitation for automations focused on keeping the database clean and debugging sends.Vote on IdeaExchange
As per the documentation,
_DataSourceName personalisation string should show the communication audience's name. It covers lists, data extensions, groups, and filters.
It works when the email is sent via Email Studio -> Email -> Content -> Send flow. However, when we send Email (or SMS) from Journey Builder,
_DataSourceName shows "All Subscribers" instead of the Entry Data Extension name. It is true for both Multi-Step Journeys, and Single Email Sends.
Vote on IdeaExchange
_DataSourceName should show Entry Data Extension Name for Emails in Journey Builder. It is handy for debugging from Send Log and creating dynamic logic in emails based on Data Extension naming convention.
The Behavioral Triggers Content Block for Emails is an excellent tool for easy drag-and-drop creation of Abandoned Engagement communication. But it is missing one powerful feature — the ability to personalise the email with customer data.
It is already available in the form of:
- Einstein User Attributes that we can pass through
- The request used in the back end of the current Behavioral Triggers Content Block; by adding "&user_attributes=attributeName" to the endpoint.
- Code of the existing Behavioral Triggers Content Block responsible for creating AMPScript variables based on the Einstein User Attributes data.
However, as the Einstein User Attributes are neither added to the request by default nor can be configured in the User Integrace of the Content Block, to get this data in the email, one must create yet another, the same call with the above query parameter added. Neither user friendly nor optimal due to expensive
HTTP.Get function running twice in such a scenario.
Salesforce can fix it. Below are two solution tiers:
- Minimum Valuable Solution: Add the required query string ("&user_attributes=X,Y") with all potential Custom Einsteins User Attributes to the request URL built within the Content Block code.
- Solution Deluxe: Improve the above with the UI-enabled selection of needed Profile Attributes, just as available with Product Attributes.
Behavioral Triggers Content Block allows for easy out-of-the-box use of abandoned engagement data in our Emails. It neatly pulls the Catalog items that captivated the customer's attention and displays them for win-back purposes. Of course, each item links back to its e-commerce page.
Its implementation is, however, leading to a problem with tracking. My favourite solution - Parameter Manager with Web Analytics Connector - is not working on the Behavioral Trigger Content Block. Neither can we add the tracking parameters manually, as there is no such option in the UI.
Right now, there are only two ways to add the UTM's:
- Add them to the Catalog directly - this adds them for all scenarios connected to Einstein or Behavioral Triggers. Not useful, as in most cases, we want to differentiate various personalisation placements by using distinct UTM tracking.
- Create a Custom Behavioral Trigger Content Block - now we will be able to leverage direct links from
IGO_PRODUCTATTRIBSadd tracking to them in the product's HTML template. Okay, but not easy and make you loose click data for Einstein Recommendations.
Salesforce can fix it. Below are two possible solutions:
- Minimum Valuable Solution: Add a text box to a Behavioral Trigger Content Block configuration menu to add our custom tracking. The Content Block should apply the provided tracking query to each link. AMPScript support included.
- Solution Deluxe: On top of the above solution, Marketing Cloud should consider the Parameter Management to allow for a mix of global UTM's from Web Analytics Connector and local from the new text box in Behavioral Trigger Content Block configuration.
There is, however, area for an easy improvement on that idea to make it much more flexible and ready for real-world scenarios. Salesforce can do it with two solutions:
Just as there are Custom Attributes for the Product Catalog, it would be great to have a similar option on the cart itself. Product Catalog ones are global - shared for all Customers interested in selected product. There is a need for something more unique and customer-specific.
It is already available in the form of an optional
price attribute of
trackCart Collect.js Data Layer that contains individual price that does not impact the Product Catalog. It would be great to have the possibility to add a few more, available in
trackCart Collect.js and the response from Einstein Backend (IgoDigital).
Use case? Sure. Coupon Code Name, Coupon Code Discount (either integer or float for per cent value), added Personalisation, Voucher ID. All those tools are frequently used in e-commerce and would be perfect for a
trackCart layer. Suitable for personalisation, perfect for passing data needed for rebuilding the cart.
This one is an extension of the above idea. We already have a way to decide which Product Catalog Attributes are displayed in Behavioral Trigger Content Block. But in many cases, when I use Abandoned Cart, I would like to show
trackCart individual price (including applied coupons) instead of the global Catalog one. It could also be useful for some Custom Cart Attributes from the previous solution.
Below are three solution tiers:
- Minimum Valuable Solution: Add
amountin the response from the IgoDigital) available for selection when defining fields shown for products in Behavioral Trigger Content Block.
- Nice Solution: On top of the first point, add two additional (optional) attributes to
trackCartCollect.js and IgoDigital response:
couponCodeDiscount- and make them also available for selection in Behavioral Trigger Content Block.
- Solution Deluxe: On top of the first point, add the possibility of defining Custom Cart Attributes in the UI and leveraging them in
trackCartCollect.js and IgoDigital response. Just as with Custom Profile Attributes / Custom Product Attributes. Additionally, make them also available for selection in Behavioral Trigger Content Block.
The current version of Behavioral Trigger Content Block is not rendering correctly on Yahoo, AOL and Windows Outlook. On those Email Providers, the product text is not displayed, and the customer only sees the images.
The reason for this is using
rem units font-size for product descriptions -
<td class="mcbt_name" style="padding: 0; font-size: 0.8125rem; padding-top: 10px; text-align: center; width: 100%; max-width: 310px;">--name--</td>
rem units are currently not supported by Yahoo, AOL and Windows Outlook (Can I Email) which leads to those Email Providers ignoring this parameter. When this happens, the font-size value is inherited from the parent that have font-size configured.
And for Behavioral Trigger Content block that parent is a
<td> parameter within header
markupFragment. Unfortunately, it has
<td class="multi-column" style="padding: 0; text-align: center; font-size: 0; padding-top: 10px; padding-bottom: 10px;">
There should be no
rem units used in the Behavioral Trigger Content Block code and instead a standard
px font-size assignment for the Block to render correctly.
SMS Blackout allows blocking SMS sends in the chosen timeframe. Currently, SMS Blackout can be configured based on Account Timezone.
However, it would be much better for multi-country clients to configure the Blackout period based on the recipient's local timezone. MobilePhone locale is perfect for implementing this.
This way, it would be possible to create, for example, single SMS Blackout for night time and apply it for each contact regardless of the timezone. The locale is already there for MobileConnect and can be leveraged for determining timezone offset.Vote on IdeaExchange