List of frequently asked questions (FAQs) about Adobe Target Recommendations activities.
Yes, Recommendations objects (Criteria, Designs, Collections, and Exclusions) created over API are now available in the UI.
No. Recommendations activities with visual offers created in the Target UI are not manageable using the Target APIs. Although these activities display in the Activities list, you cannot read or update them (using GET/PUT).
When you perform a catalog search on a custom attribute with a numeric value, the results treat the custom attribute to be a string type instead of a numeric value.
Currently, there is no functionality available that allows customers to change the type of an attribute. To make a change, open a customer issue referencing the attributes that need the type changed from string to numeric.
The time frame and results vary, depending on how the items are updated.
Source | Details |
---|---|
Item attributes updated via mbox or API |
|
Item attributes updated via feed |
|
Item deleted from the catalog via Target UI or API |
|
Item added to the catalog via mbox or API |
|
Item added to the catalog via feed |
|
After importing a feed file, or after receiving entity updates via API or mbox, the following changes are reflected in under 60 minutes:
If an item was previously excluded but should now be included, the item will be included on the next algorithm run (12-24 hours).
This situation occurs because Target applies exclusions both online and offline. When an item is newly excluded, the online exclusion applies quickly. When an item is newly included, the online exclusion goes away quickly but the offline exclusion doesn’t go away until the next algorithm run.
If an item was previously included but should now be excluded, the item is excluded per the “Item attributes updated…” time line discussed above depending on feed source (15 minutes via mbox/API or 12-24 hours via feed).
The following changes are not reflected until the next algorithm run occurs (within 12-24 hrs):
A feed file is considered imported when its status changes from “Importing Items” to “Preparing Search Index Updates”. Updates can take more than 60 minutes to be reflected in the Catalog Search user interface; Catalog Search is up to date when the feed status changes to “Updates Completed”. Even if Catalog Search is not yet up to date, your site reflects updates on the time frames listed above. The most recent Catalog Search index update time is displayed on the Catalog Search page.
A change to the promotion settings can take up to five hours to be reflected onsite.
A change to other criteria settings might not be reflected until the next algorithm run:
The behavior of users in aggregate is incorporated into offline algorithm processing with every algorithm run occurring every 12-24 hours.
Use escaped values in JavaScript. Quotation marks ( " ) can break the array. The following code snippet is an example of escaped values:
#set($String='')
#set($escaper=$String.class.forName('org.apache.commons.lang.StringEscapeUtils'))
<script type="text/javascript">
console.log("$escaper.escapeJavaScript($entity1.name)")
console.log("$escaper.escapeJavaScript($entity2.name)")
console.log('$escaper.escapeJavaScript($entity3.name)')
names.push("$escaper.escapeJavaScript($entity4.name)")
</script>
The available criteria is based on the current category. When you are creating recommendations offers, the algorithm picker displays criteria based on category Id.
If the location on which you’re applying this criteria doesn’t contain the category Id, certain criteria is not available in the algorithm picker.
If you use a location where category Id is present in the mbox, the criteria picker contains all applicable criteria.
Target has a Filter Incompatible Criteria setting to control intelligent filtering of the algorithm picker.
This setting applies to activities created in the Visual Experience Composer (VEC) only. This setting does not apply to activities created in the Form-Based Experience Composer (Target does not have location context).
To access the Filter Incompatible Criteria setting, click Recommendations > Settings:
If the Filter Incompatible Criteria setting is NOT enabled, Target does not filter algorithms in the Algorithm Picker and all algorithms are displayed.
If the Filter Incompatible Criteria setting is enabled, in VEC activities, Target reads entityId and category Id from the selected location and then displays algorithms based on currentItem|currentCategory
(if respective values are present on that location). As a result, only compatible algorithms for the selected location are shown in the algorithm picker, by default.
If the Filter Incompatible Criteria setting is enabled, you can still view non-compatible algorithms by deselecting the Compatible checkbox while selecting criteria.
The following list contains special cases in which Target does not display the Compatible checkbox:
Consider the following information if you see a collection go to zero that previously was not at zero:
You can resave the collection and see if it updates the number. By resaving, the collection reruns all algorithms that are using that collection.
Are you looking at the right environment? Go to /target/products.html#recsSettings to double check (as shown below).
Is your index up to date? Go t o /target/products.html#productSearch and check how many hours old the index is (for example, “Indexed 3 hours ago”). You can refresh the index as needed.
Did you change something in the feed or the data layer that resulted in your entities no longer matching the collection rules? Make sure your CASE matches (case-sensitive).
Did your feed run successfully? Did someone change the FTP directory, password, and so forth?
Target does its best to make updates to the delivery (on the customer’s page/app) happen as quickly as possible. Yet, Target also has to provide some representation in the UI for the marketer. Target does not delay delivery updates to wait for the UI updates to be in sync. You can use mboxTrace to see what is in the system at the time a request comes in.
Attribute weighting exists in two forms: “standard attribute weighting” and “content similarity attribute weighting.”
“Standard attribute weighting” applies to most, if not all, criteria types (not just Content Similarity). This type of weighting gives more weight to certain attribute values. In the following example, Nike products get a bump in the output recommendations.
“Content similarity attribute weighting” applies to Content Similarity criteria only.
This type of weighting is more dynamic, and is based on the current “recommendation key” (the currently viewed item). In the following example (brand x 16), if a visitor were viewing Nike sneakers, that visitor is more likely to be recommended other Nike products (not necessarily only sneakers) rather than competitors’ sneakers. If a visitor is viewing Adidas sneakers, that visitor is more likely to be recommended Adidas products.
Target sometimes cannot show recommendations due to the low number of available recommendations.
The number of values generated per criteria is three times the number of entities specified in the design. Runtime filtering (for example, inventory, mbox attribute matching) is applied after the 3x values are generated, so it is possible end up with fewer than 3x values at delivery time. To mitigate this situation, increase the number of entities in the design by hiding other entities.
The following JavaScript can be used at the beginning of the design to increase the number of requested entities. In this example, the requested entity count would be 30 (3x10).
#foreach($entity in $entities)
#if( $foreach.count > 10 )
#break
#end
#set ($foo = $entity.id)
#end
Target imposes a 50-MB post limit at the application level; however, that is only when you pass the application/x-www-form-urlencoded
content type header.
You could certainly try to send 50,000 products in a single call. If it fails, you can break it up into batches. Adobe recommends that customers break their calls into 5,000 or 10,000 product batches to decrease the likelihood of a timeout due to system load.
When creating a Recommendations criteria, promotions, or template testing rule based on an mbox parameter, mboxParameter
no longer prompts you for mboxName
. mbox name is now optional. This change lets you use parameters from multiple mboxes or reference a parameter that has not yet been recorded on the edge.
To select the desired parameter:
Using either method, there is no link between the mbox and the parameter. The criteria, promotion, or template testing rule works based on parameter across all mboxes that pass that parameter.
If you edit an existing criteria, promotion, or template testing rule, the filtering criteria displays with the mbox name that was supplied during creation.
Ensure that the audience has a unique name. If you gave the audience the same name as an existing audience, you cannot save your legacy Recommendations activity (a Recommendations activity created before October 2016).
There is no hard limit on the number of rows or file size for a feed’s CSV file upload. However, as a best practice, Adobe recommends limiting the CSV file size to 1 GB to avoid failures during the file upload process. If the size of the file exceeds 1 GB, it can ideally be split into multiple feed files. The maximum number of custom attribute columns is 100 and custom attributes are limited to 4096 characters. Other limits on the length of required columns are available on the Target Limitations page.
In the query string, you can pass entity IDs for entities that you want to exclude from your recommendations. For example, you can exclude items that are already in the shopping cart.
To enable the exclusion functionality, use the excludedIds
mbox parameter. This parameter points to a list of comma-separated entity IDs. For example, mboxCreate(..., "excludedIds=1,2,3,4,5")
. The value is sent when requesting recommendations.
The exclusion is performed for the current Target call only; items are not excluded on subsequent Target calls unless the excludedIds
value is passed again. To exclude items in the cart from recommendations on every page, continue to pass the excludedIds
value on every page.
If too many entities are excluded, recommendations behave as if there aren’t enough entities to fill the recommendation template.
To exclude entityIds
, append the &excludes=${mbox.excludedIds}
token to the offer content url. When the content url is extracted, the required parameters are substituted using current mbox request parameters.
By default, this feature is enabled for newly created recommendations. Existing recommendations must be saved to support Dynamically Excluded entities.
NO_CONTENT is returned when recommendations are unavailable for the requested algorithm and key combination. Generally speaking, this situation occurs when backups are disabled for the algorithm and one or more of the following is also true:
Results are not yet ready.
This situation typically occurs when first saving a newly created activity or after configuration changes are made to the collection, criteria, or promotions used in the activity.
Results are ready, but not yet cached at the nearest edge server, for the requested algorithm/key combination.
The request initiates a caching operation, so this issue should resolve itself after a few page reloads and/or a few minutes pass.
Results are ready, but not available for the provided key value.
This situation typically occurs when requesting recommendations for an item that was added to the catalog after the most recent algorithm run and will resolve itself after the next algorithm run.
Partial template rendering is disabled and not enough results are available to fill the template.
This situation typically occurs when you have a dynamic inclusion rule, which aggressively filters many items from the possible results. To avoid situation, enable backups and do not apply the inclusion rule to backups, or use the criteria in sequence with a less-aggressively filtered criteria.
When a visitor initiates a session, the session ID is tied to a single edge machine and a temporary profile cache is stored on this edge machine. Subsequent requests from the same session read this profile cache, including recently viewed items.
When the session ends (generally, when it expires after 30 minutes of no activity), the session state, including recently viewed items, is then persisted to a more permanent profile storage in the same geographic edge.
Subsequent sessions from different devices are then able to access these recently viewed items as long as the new session is linked to the customer profile via the same Marketing Cloud ID (MCID), Experience Cloud ID (ECID), or CustomerID/mbox3rdPartyId.
If a visitor has two active sessions at the same time, recently viewed items on one device do not update the recently viewed items on the other device, unless the devices are forced to share the session ID. There is a potential workaround for the issue, but Target does not directly support sharing a session ID across multiple devices. The customer must manage this ID sharing themselves.
This behavior still occurs if a visitor is active on one device and then becomes active on the other device a few minutes later. The first device’s session does not expire for 30 minutes and there can be up to five minutes of delay before the profile state is written to the permanent state and processed. Allow 35 minutes for the session to expire and the profile to be stored when testing this behavior.
If the visitor does not have two active sessions at the same time, recently viewed items on one device update the recently viewed items on the other device as long as the session has ended. Allow 35 minutes for the session to expire when testing this behavior.
An algorithm created in Recommendations Classic is not supported in Recommendations Premium. You might be able to use the legacy algorithm in Target Premium; however, the algorithm can create sync issues when deactivating or deleting the activity in the Target Premium UI. For more information about the differences between the two solutions, see Recommendations Classic versus Recommendations activities in Target Premium.
Some customers in media and publishing want to ensure that recommended items include only the newest articles or videos. As an example, a Target customer used the following approach to recommend articles fewer than 60 days old:
publish date > today's date minus 60 days
.Entity attribute | Example |
---|---|
issueDate | 2021218 |
lastViewDate | 2021701 |
parentCategory | commentary |
publishDate | 20210113 |
publishDateDisplay | Jan 13, 2021 |
This example could also be accomplished using parameter matching and passing the priorDate60
value as an mbox parameter.
The following are known issues with Recommendations activities: