By sending workflow data as the test proof instead of the test profile would allow us to validate that the variables within the workflow are accurate and provide us a view of what the customers are receiving.
I believe you are suggesting being able to send proofs using real customer data accessible via the workflow, as opposed to only being able to send proofs using the fake test accounts. I am 100% for this. Given the many profile table and other attributes that go into personalizing campaigns, forcing users to create test profiles in order to send proofs to evaluate the display of dynamic content is really time consuming and barely scratches the surface of being able to show the diverse data that is only found among real user profiles. It would be a huge benefit if we can test proofs using real eligible users instead of creating test profiles!
We want to manage proof with Profile data, which means we will access to all workflow environment.
For this, we will use the notion of Address substitution, like we do in ACC. There is still no release date, but this is how we want to achieve this.
For now, a workaround is to send 2 different deliveries with a first target for proof recipients (who came from profiles), and then a second delivery with the real audience.
While not exactly the same as substitution on ACC, there is one way of doing this in ACS that I've recently come across using Trap on a Test Profile. Try the steps below
Create a test Profile and enable “Proof” and “Trap” flags on it. A Test Profile flagged with the “Trap” becomes a part of the targeted audience rather than being just a test profile for Proofs.
The way the Trap works is that for any enriched (targetdata) fields in a delivery, the targetdata fields are picked at random from a Target Recipient and assigned to this Test Profile (flagged with Trap).
This makes the targetData available for a Test Profile.
Steps to implement
Create a Test workflow generates some target Data
Add an email to this workflow and while configuring the email, select the Test Profile on which Trap was selected.
When the delivery gets analyzed as a part of the workflow run, you’ll notice that the target count includes the Test Profile selected above.
When the delivery goes out, it can be seen that the targetData which typically shouldn’t be available for a Test Profile is now been substituted by data from a “Real profile”.
I’ve attached an image showing the Profile vs Test Profile and how the test Profile now contains data from a Profile.
In my example, 89 was an account number assigned to a Profile as a part of the data load activity, but as you can see, it was assigned to the account number of test profile. Please note that this approach will not substitute any data other than the targetdata(e.g it won't substitute first and last name of test profile with a real user)
Please let me know if this yeilds any incorrect/unexpected results.
The question is relating to targetData from the workflow (e.g. segment code), not Profile data.
Example - create a target audience, use the Segment activity to filter audience into 3 different segment codes, then use this targetData to personalise a banner in an email/push.
There is no way to preview this as you can't currently enter test targetData.
This use case is not covered by substitution of address functionality.
