Out of the box there is not solid solution without some level of coding.
Either route requires making another mbox call unless you hold up the
first one which might impact the user experience. Here are the two
options I have entertained in the past:1. Use an Adobe Launch rule to
listen to a custom event or data element related to the data you are
waiting from the API. Then fire another Adobe Target global mbox with
the parameters including the data you need for Target to qualify the
user for the...
@umamaheswariy46 To answer your question, you need to create a "project"
within adobe.io and would add to the project your product, in this case
Adobe Target. In here you can then select the product profile that
should map to what you have in Admin console. In admin console is where
you create the group with the rights they need. Separate question, the
third party tool is going to upload user data into Adobe Target? Is it
users your digital channel has seen before? Because if not it will not
ret...
I agree on the data servers being an issue.Why are they on different
tracking servers? Get them on the same tracking server and make sure
they both have the same supplemental IDs.
@LordOfTheRings Yes this is perfectly fine, the library needed for
either type(SPA or non SPA) are the same. The only time it will vary is
for server side or the mobile sdks. For the SPA pages you will just want
to set up event listeners for Launch to fire the proper Target method
i.e triggerView, getOffers, etc. Let me know if you have any additional
questions.
@umamaheswariy46 I would recommend reviewing this documentation very
carefully. Also can you described the steps you have taken already? Want
to make sure I understand how you generated your JWT token as an
example.
Unfortunately this meta data is not returned in the API. I would suggest
in the next coffee break with the Target product owner that it gets
mentioned. Perhaps they can mention if something is out there an not
documented or future plans to provide more meta data in the API service.
Which metrics is this? I am trying to figure out if you are having issue
with data is passing in from your app into Adobe Analytics or from
Target to Adobe Analytics via A4T. Also how are the activities
configured? It sounds like you have an experience with additional
"pages". Also is this a native app or mobile browser?
@CorralesD We dont have the ability to make seperate calls from the
profile script. You should do this before calling Target and then
passing it in the parameters of the mbox call.
I would ask the front end application to limit the characters because
you have a limit in AA. In my experience AA does not do well with such
long values in terms of getting insights. Or you can work with product
team to capture only first 255 character in evar. Best of luck.
Yea I was having hard time finding it in the java doc as well. I would
look closely at sample code to see where the value is typically set and
use the same options provided in the nodejs documentation. My
recommendation outside of documentation is confirm with client support.
Check this link out. You will find a section called "How it works" first
row on the table calls out the options.
https://github.com/adobe/target-nodejs-sdk-samples/tree/master/on-device-decisioning
The AAM API is specific for interacting with the same capabilities you
could have in the AAM UI. So creating/editing/deleting traits, segments,
data source, profile merge rules, getting data of a particular segment
as examples. It is not the API to do ID syncs or getting a specific
users data, or for sending user data.
https://experienceleague.adobe.com/docs/audience-manager/user-guide/api-and-sdk-code/rest-apis/aam-api-getting-started.html?lang=en#api-urls
Here is my recommendation. You have two instances, Website A will have
Appmeasurement for Analytics with ORG1. Website A should have S2S
forwarding with AAM. That is BAU. On Website A, you have two options for
sending the data to your second AAM instance. Option A using DIL or
Option B using your Website B Adobe Analytics instance also on Website A
(the instance with the same org ID as your second AAM instance). You
would have this set up as S2S as well. Either route, you will end up
with multip...
You would have 1 DIL instance for the "website 2" AAM instance. Your AA
and AAM for website 1 should be using server side forwarding. You send
data to the website 2 AAM instance using DIL with the configured Adobe
Org ID. If you want to use the data sent to the AAM instance using the
DIL code you need to understand that for site activation both of the
instance need to be on the same web domain. WHen the DIL code creates an
instance it will create a cookie for that specific domain you are on.
So what I shared still applies, you can do it on the client side but
will need to have jobs to export the data and send it to the other
instance. I really think you should contact Adobe about the server side
Launch beta. I think it would be a great fit and it would be something
that would be more efficient and scalable. Here is documentation on it.
Here is the link, read under "Enable Launch Server Side"
https://experienceleague.adobe.com/docs/launch/using/server-side-info/server-side-getting-st...
Ok I follow now better I think. So yea you want to pass in
entity.category so Target can track the category of the product, if you
want to pass in specific category affinity about the user based on data
you might have you can pass that in as well under user.
@anubhavs4404437 You need to pass in the entity.id at a minimum to
provide product recommendations. If you want to use category affinity
you would need to also pass that in.
The cookie needs to be seet seperatly. That could either be a script on
the page that listens for a click to the specific buttons in scope or
perhaps an event listener in Adobe Launch for again the buttons in
scope.
Do you have a separate Launch and AA instance with the AAM instance you
are trying to use on site A? If not than why not just move it there,
that would simplify everything for you. From a server side standpoint,
right now my understanding is you can only map AA and AAM instance on
the same ORG ID for S2S integration. On the client side you can have
both separate, but if you want to do anything with that AA data under
ORG1, it won’t be forwarded to ORG2. Instead you will need to reconcile
offline...
The Audience Manager REST API is to interact with the actual tool versus
to UI. Like to create segments, traits, to pull performance data for
segments and traits, and etc. It isnt use to onbooard user data as an
example or to do an ID sync, or to pull data about a specific user.
@1982luca I dont think I am following, are your questions is clear
enough for us to understand. The DCS API is the same endpoint used by
the ID Sync service. When you say AAM API, are you speaking about the
pixels you can fire?
Additionally, I am interested more on your use case because it might be
a good fit for the new server side Launch capabilities where you have
forward on the server side data to other Launch Org IDs.
Can you share a little bit more about the use case? It sounds like the
AAM instance is either from a 2nd party data partner or another company
part of your greater company. If so I am trying to get more information
on 1 use case I have seen where there was multiple instances but it only
worked because they both were for the same domain. So the site had 2
AMCV cookies but with different Org IDs. The cookie names where
"AMCV-ADOBEEORGID1" and the other was "AMCV-ADOBEEORGID2".
@anubhavs4404437 You dont need Audience Manager for your use case. I
would recommend Audience Manager if you are onboarding user data from
your internal data warehouses as an example or if you want to use data
that flows into Adobe Analytics into Audience Manager. Theres more use
cases but for this one you can I believe your main option is going to be
passing this data as a parameter to Target in an mbox, ideally the
global mbox since that is more commonly used and typically
autogenerated. I am ...
@kinggi My personal opinion is that while the products have different
variations, they are different products right, and I am guessing they
each have their own specific use case. I have seen in the past where its
the same product but each sku was just a different count, so like 1
pack, 6 pack, 12 pack, and they all used the same image. They all had
different price points though. With that example though, some people
want the larger packs right so that is a legitimate product and
recommendation t...
