David Son is a Senior Product Manager for Adobe Target where leads product strategy for mobile, APIs, and SDKs. He holds a B.A in Computer Science from the University of California, Berkeley and is based in San Francisco.
Curious about what an Adobe Target Community Q&A Coffee Break looks like? Check out the threads from our first Series of Adobe Target Community Q&A Coffee Breaks and from our last Break from 10/14/20 with Jon Tehero, Group Product Manager for Adobe Target
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi @DavidSonPM - My question: When leveraging Target Premium for mobile, do we need a global mbox in a mobile app? It is standard practice on the web, but we're having trouble finding clear documentation on mobile app use cases and technical requirements.
@katsaks wrote:Hi @DavidSonPM - My question: When leveraging Target Premium for mobile, do we need a global mbox in a mobile app? It is standard practice on the web, but we're having trouble finding clear documentation on mobile app use cases and technical requirements.
When calling Target from our Mobile SDKs, you can retrieve experiences for a given mbox. If you are familiar with Target and have used Target for the past few years, you might know them as regional mboxes. If you have form-based composer activities that are set up with target-global-mboxes then you can retrieve experiences via the target-global-mbox. Here is the API docs for more information - https://aep-sdks.gitbook.io/docs/using-mobile-extensions/adobe-target/target-api-reference
@DavidSonPM are you able to confirm that we only call AAM s2s from Target when there is an activity that is using an AAM segment? Thus not impacting AAM server call limits.
Thanks!
@josejr19 wrote:@DavidSonPM are you able to confirm that we only call AAM s2s from Target when there is an activity that is using an AAM segment? Thus not impacting AAM server call limits.
Thanks!
The S2S call is a backend setting that can be configured to be real-time (once per page) or session-based (once per session). It is not directly tied to the usage of the segments in an activity.
We are developing a mobile web SPA for our financial clients that will be hosted on our client sites via iframe structure. The base code of the SPA will remain the same across all clients and we plan to implement at.js 2.x some time next year. I have a few questions:
1) Can we use Visual Exp Composer (VEC) to create a single A/B testing activity for all the clients that we plan to run target test? Since our SPA will be hosted by many different site. If we create a test for each client, that would be hard to manage.
2) Does VEC support SPA inside of an iFrame?
3) Is Form based EXP Composer (FEC) a better choice in this scenario? If so, i'm not sure how to reference the "view" using FEC.
4) Can a “view” be nested inside of another “view”?
@ca90883831 wrote:We are developing a mobile web SPA for our financial clients that will be hosted on our client sites via iframe structure. The base code of the SPA will remain the same across all clients and we plan to implement at.js 2.x some time next year. I have a few questions:
1) Can we use Visual Exp Composer (VEC) to create a single A/B testing activity for all the clients that we plan to run target test? Since our SPA will be hosted by many different site. If we create a test for each client, that would be hard to manage.
2) Does VEC support SPA inside of an iFrame?
3) Is Form based EXP Composer (FEC) a better choice in this scenario? If so, i'm not sure how to reference the "view" using FEC.
4) Can a “view” be nested inside of another “view”?
1) A/B activities are delivered to a website according to the template url settings. You can deliver 1 AB activity to multiple different sites with different domains if that is what is being asked here.
2) I am not quite sure about this. Our At.js needs access to the DOM tree to make changes to the content. I will follow up on this.
3) The View concept is used only when you want to use the VEC for your SPA. Form-based composer returns data in the format like JSON, HTML, IMage, etc. So you don't need to use Views when you use form-based composer.
4) Views don't have a tree structure in Target. They are flat objects.
Thanks David. @DavidSonPM
Regarding Question #1, when creating a A/B test using VEC, the first step is to enter a activity URL. Since we plan to run our test in many different bank sites, what URL shall I use? FYI. our application will be hosted inside of iframe by our clients.
Will you follow up with me via email?
Views
Replies
Total Likes
@ca90883831 wrote:Thanks David. @DavidSonPM
Regarding Question #1, when creating a A/B test using VEC, the first step is to enter a activity URL. Since we plan to run our test in many different bank sites, what URL shall I use? FYI. our application will be hosted inside of iframe by our clients.
Will you follow up with me via email?
I have just received confirmation that VEC cannot work for applications within iFrames unfortunately.
@DavidSonPM wrote:
@ca90883831 wrote:Thanks David. @DavidSonPM
Regarding Question #1, when creating a A/B test using VEC, the first step is to enter a activity URL. Since we plan to run our test in many different bank sites, what URL shall I use? FYI. our application will be hosted inside of iframe by our clients.
Will you follow up with me via email?
I have just received confirmation that VEC cannot work for applications within iFrames unfortunately.
To expand here, an activity that is sourced from outside the iFrame cannot "reach" into the iFrame to manipulate the DOM. It is walled off. You could theoretically have Target deployed inside of the iFrame as well but this is largely untested and not officially supported.
Thanks David and Jason. @DavidSonPM
Correct, our SPA will reside inside of iframe on our different client bank sites. and it's our plan to run target test inside of iframe. That said, Form based composer is the only option right? and we don't need to utilize "view" in that case?
@ca90883831 wrote:Thanks David and Jason. @DavidSonPM
Correct, our SPA will reside inside of iframe on our different client bank sites. and it's our plan to run target test inside of iframe. That said, Form based composer is the only option right? and we don't need to utilize "view" in that case?
If you can navigate to the iFrame directly via internal tools and/or an administrator view, you likely could still use the VEC. if the SPA itself can't be loaded by an Adobe Target author directly, you likely could not. I doubt it is possible to diagnose without trial and error so I would encourage you to experiment and validate that actions are applying properly and sessions and profile data is being tracked properly.
Hi David
Would you know when the Redirect+A4T issue is being fixed (https://experienceleague.adobe.com/docs/target/using/release-notes/known-issues-resolved-issues.html...) ?
2. Does using redirects in generell generate less visitor data as the redirect need some time to execute? (in an A/B where B is has a redirect configured A would thus always have more visitors?)
3. Adobe Consulting mentioned that is is "best practice" to have redirect on all Experiences when using redirect in and A/B Tests in order to have an equal configuration. Can you confirm this (however redirecting to the same URL is not possible - should we use a dummy URL parameter here).
I have a question about integrating Target into a single-page application that mainly relates to experience type activities. The specific use case is for content that is setup to be displayed in a container that is shared across multiple screens in the SPA. What is the best way to manage hiding/showing the content when it is intended for only one of the screens?
To elaborate, without explicitly hiding or removing the content when the user transitions to a new screen, the content would continue to appear in the "global" container. Conversely, once the content is hidden or removed, it will not re-appear when the user transitions back to the original screen without explicitly re-inserting or un-hiding the content.
Any guidance on the best way to do this is much appreciated.
What are the main Target changes that we need to be prepared for when transitioning to Alloy?
@tszat wrote:What are the main Target changes that we need to be prepared for when transitioning to Alloy?
I would say the main changes you need to be aware of are how audiences work. You must configure XDM in order to use Target for Alloy.js When defining Audiences for your Target activities that will be delivered via the AEP Web SDK, XDM must be defined and used. After you define XDM schemas, classes, and mixins, you can create a Target audience rule defined by XDM data for targeting. Within Target, XDM data displays in the Audience Builder as a custom parameter. The XDM is serialized using dot notation (for example, web.webPageDetails.name).
If you have Target activities with predefined audiences that use custom parameters or a user profile, be aware that they won’t be delivered correctly via the AEP Web SDK. Instead of using custom parameters or the user profile, you must use XDM instead. However, there are out-of-the-box audience targeting fields supported via the AEP Web SDK that do not require XDM. These are the fields available in the Target UI that do not require XDM:
Please see this doc for more information - https://experienceleague.adobe.com/docs/experience-platform/edge/personalization/adobe-target/target...
Haven't heard much about Alloy and native app? I assume that is also coming.
Quick UI feedback on trying to read the delivery API doc. When I'm scrolling through it, it autoscrolls me back up towards the beginning of the doc.
I'm using Chrome V86.0. Similar behavior seen in Chrome Incognito.
@jonathanl557422 wrote:Quick UI feedback on trying to read the delivery API doc. When I'm scrolling through it, it autoscrolls me back up towards the beginning of the doc.
I'm using Chrome V86.0. Similar behavior seen in Chrome Incognito.
http://developers.adobetarget.com/api/delivery-api/
We use ReDocs for generating API docs and this is a known issue in Chrome. You won't see this problem in Firefox. I suggest using Firefox for the time being. We are also in the progress of migrating to Gitbooks. You will slowly see the API docs also migrated there. In the meatime, SDKs are documented here - https://adobetarget-sdks.gitbook.io/docs/
@DavidSonPM wrote:
@jonathanl557422 wrote:Quick UI feedback on trying to read the delivery API doc. When I'm scrolling through it, it autoscrolls me back up towards the beginning of the doc.
I'm using Chrome V86.0. Similar behavior seen in Chrome Incognito.
http://developers.adobetarget.com/api/delivery-api/
We use ReDocs for generating API docs and this is a known issue in Chrome. You won't see this problem in Firefox. I suggest using Firefox for the time being.
We are also starting a process of moving to a new (and better!) docs portal for our API documentation - stay tuned for news on that in future release notes.
I have the same issue and I'm also on Chrome.
Any plans to enhance data available in API? We previously looked at it for a reporting dashboard (detail what is currently running and where) and found that it didn't seem to have access to all the information we would want to have.
Views
Likes
Replies
Views
Like
Replies
Views
Likes
Replies
Views
Likes
Replies