I reviewed my QA links and believe I am ready for "Activate".
Will clicking "Activate" throw any errors? What other safeguards might Adobe Target have? Or does it launch the test no matter what?
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Hi @will1234,
basically you should do a thorough QA (I also recommend a QA by more than one person). Also accordingly the metrics. After that if you have the rights - you can activate it. Then it is also live.
It's better to invest more time in the QA phase - than to have to shut things down later when something doesn't work as expected.
Additionally (doesn't come out of the box)
Personally I check in the JavaScript code of the activity itself if on the one hand the page structure is as expected, if everything is there what I assume. Also if all requests work etc. if any of it is not as expected - then I write corresponding logs and write data into the DataLayer - which I can evaluate in an error dashboard.
Basically you have to expect that the page structure changes without you being informed - or a request doesn't work as expected. Just for this it is important that the activity contains so much logic that it represents the original again in case of emergency. So that the user does not notice anything.
Basically, I think it's good that Adobe Target doesn't check too much here. I know other tools where errors are generated when I want to insert CSS - which includes selectors that are not yet on the page. But that's not good - if I want that explicitly, because e.g. code is loaded by a react component at a later time.
Hi @will1234,
basically you should do a thorough QA (I also recommend a QA by more than one person). Also accordingly the metrics. After that if you have the rights - you can activate it. Then it is also live.
It's better to invest more time in the QA phase - than to have to shut things down later when something doesn't work as expected.
Additionally (doesn't come out of the box)
Personally I check in the JavaScript code of the activity itself if on the one hand the page structure is as expected, if everything is there what I assume. Also if all requests work etc. if any of it is not as expected - then I write corresponding logs and write data into the DataLayer - which I can evaluate in an error dashboard.
Basically you have to expect that the page structure changes without you being informed - or a request doesn't work as expected. Just for this it is important that the activity contains so much logic that it represents the original again in case of emergency. So that the user does not notice anything.
Basically, I think it's good that Adobe Target doesn't check too much here. I know other tools where errors are generated when I want to insert CSS - which includes selectors that are not yet on the page. But that's not good - if I want that explicitly, because e.g. code is loaded by a react component at a later time.
- You can setup the test URL to force an experience to show up in the page for unit test and fix any layout issues.
- I believe user test will be one of the important parts of the testing where the experience is delivered to a test user without any enforcements. this is where you check if your segmentation rules & priority is working as expected.
Note:
- One items to remember all the reporting you will see in target interface from target delivery prospective. Meaning Target will report on all campaign it's delivery (Not on displaying the content was successful or not).
- Another area if a customer qualifies for multiple campaigns with same priority, it will deliver all the campaigns to the destination page and the page code will pick one for display. Meaning Target reports will show higher delivery compared to the reports in analytics (saying that if you have done the a4t implementation correctly)
Views
Like
Replies