Acquia CDP
1851 Release - 2019-01-17
Currently a work in progress…
| Area | AgilOne JIRA | Description of functionality after the fix |
|---|---|---|
| Platform | AGO-10750 | Master customers with over 10,000 transactions are no longer labeled as ‘Non Buyer’, they are now labeled more appropriately as ‘NA - High Volume Buyer - 10k+ transactions’. AgilOne sets aside master customers that have over 10,000 transactions during our business intelligence calculations because they can delay (or prevent) the completion of our overnight refresh process, without adding any real value for our clients. Previously when we set them aside we did not label them properly. |
| Platform | AGO-11557 | When two child customers that have been de-duplicated together have conflicting information (such as two conflicting acquisition sources), we have to specify how to choose the winning acquisition source to promote to the master customer. For something like acquisition source we may want to promote the acquisition source of the earliest created customer profile. We have squashed a bug that, instead of promoting the earliest created acquisition source, was promoting the least recently updated acquisition source. |
| Actions: Facebook Output Connector | AGO-11594 | Due to a recent update to Facebook’s Custom Audience API, an AgilOne Actions Facebook campaign would fail during the 2nd+ execution of a campaign, when the audience being exported differed from the previous audience exported by <= 200 individuals. We have implemented a fix to prevent Facebook campaigns from failing during these specific circumstances. |
| Actions & 360 | AGO-11125 | A few clients that use AgilOne Actions to export mailing addresses have complained that the apartment number (i.e. suite number) is sometimes stored in customersummary.suite (when the address is DPV confirmed), and at other times stored in Address1 or Address2 (when the address could not be DPV confirmed). This means that a complete mailing address in AgilOne is address1 + address2 + sometimes suite + city + state + zip + country. To avoid users from having to export suite and use it conditionally, we are now concatenating the apartment number to the end of address1. This means that a complete mailing address is now address1 + address2 + city + state + zip + country. Any information in CustomerSummary.Suite is now redundant and no longer be required for export from AgilOne Actions. |
| Platform | AGO-11262 | Some web events were not being counted properly during our customer summary calculations for FirstVisitDate, LastVisitDate, TotalVisitCountLast30Days, TotalVisitCount31_60Days. We are now properly counting all web events when performing these calculations. |
| Actions | AGO-11459 | We have greatly improved the performance of AgilOne Actions campaigns that reference transaction data. For example, the Purchased a Product audience filter or Last Products Purchased content model. |
| 360 | AGO-11514 | A bug was causing transactions for customers with really short customer IDs to either be missing from 360 or surface transactions from other customers. This bug has been fixed. Within 360, transactions should no longer be missing for individuals with short customer IDs. |
| Platform | AGO-11539 | We have added a new attribute to our household summary table: Do Not Mail. We now promote the direct mail opt-out status of the household address from the winning master customer’s profile to the household’s profile. Custom promotion logic can be implemented by AgilOne Services if you so desire. |
| Actions: Euromessage Output Connector | AGO-11630 | In order to support sending SMS campaigns via EuroMessage, we have added the ability to specify any customer-level attribute as the primary key (e.g. primary phone number) when pushing data from AgilOne to EuroMessage. Previously, AgilOne’s EuroMessage output connector only allowed email address as the primary key. |
| 360 | AGO-11643 | For clients that are integrated with AgilOne’s 360 API for call center or clienteling purposes, we have enhanced the 360 API to be able to return only the data types that are required. If your use case requires customer and transaction data only, and all of the event data is bloating your integration, you can request customers and transactions specifically as follows:
The possible field inputs include:
|
The information contained herein is subject to change without notice and is not warranted to be error-free. If you encounter any errors, contact Acquia Support.
Acquia CDP