Is there a reason you sending the data to a new Report Suite? Is this
just for testing purposes?In an ideal world you want to be able to see
your website behavior tied to your AC activities which generated the
traffic. As such you would push your AC data into your website Report
Suite not a separate RS.
Have you checked these reports against the AC metrics rather than
Pathing on the prop or an evar is your best option to understand
previous and next kw searches but could be difficult to work with if you
have a lot of data to analyse.(Hi Kate!)Hi rkverma1_99Looking at your
problem specifics you can "stack" using the plugin
s.crossVisitParticipationIt is recommended you engage with a qualified
partner or adobe consulting before playing itYou can set the expiry to
the day (i dont think it can be configured to session/visit). you can
then pass the value of the KW...
Hi Marina,The metrics pertaining to Campaign Execution:Adobe Campaign
SentAdobe Campaign OpenedAdobe Campaign ClickedAdobe Campaign
ProcessedAdobe Campaign DeliveredAdobe Campaign Unique OpenAdobe
Campaign Unique ClickAdobe Campaign UnsubscribedAdobe Campaign Total
BouncesAdobe Campaign Executed Delivery ID InstancesAre associated to
the variables:Delivery ID (Internal Delivery Name that you see in
Campaign)Delivery Label ((Delivery in Campaign – Individual
Found an oldie but a goodie.Summit Topic #1: Visitor Scoring in
SiteCatalyst | Adobe
note that the example in this article is a bit old and you no longer
need to include the s.products line item in order to set the event and
eVar to increment.
I would suggest using a counter eVar and numeric success event and
passing and increment to the eVar and event on each page load for the
specific pages.You could do this in DTM or similar TMS Alternatively you
could also us processing rules which would give the business user
greater control over modifying the pages that should increment the
engagement event.Considering the concept that not all pages are made
equal and other interactions such as pdf download, interaction with a
tool such a a loan...
I will provide my 2 cents to see if we can stimulate a discussion.You
are correct - For pathing its no longer necessary to use a prop in
workspace.I see Adobe customers using props far less these days and no
longer map props to eVars unless there is a specific need.Given that you
have a finite number of eVars and probably an excess of props it can be
useful to set other values into your props on each hit to help with
debugging (for example version of app measurement library, user agent)
You will probably be populating that tracking code report via a query
string value such cid=TRACKINGCODEYou would have a DTM rule or
which captures the value of that QS parameter and sets it in the
s.campaign variable.You can check that this is working in realtime by
using the Adobe Debugger.
Hi there,I would suggest you look at migrating to the Marketing Cloud ID
service as this is the recommended approach for all customers (replacing
the legacy solution specific cookies). Is there a particular barrier for
you migrating ?Once migrated you can leverage customer
did say you did not want to use the MCID so The only other alternatives
I can think of is to classify the eVar which holds the identifier
Hi , No it is not set automatically by the solution.More information on
how it can be set is found
the value is polluted in your reports it might be useful to run a report
to identify examples of the pages which are passing the "dirty values"
so that you can get your developers to address them.
Have a look at this plugin and see if it helps
am not sure it is supported in the AppMeasurement.js (will update u) but
help section references s_code so it should be good in there.