After testing, I can confirm- the global variables only fire on s.t
beacons. They may hang around until an s.tl beacon, but they're not
freshly set for s.tl beacons. If you fire clearvars after a page view,
you will not have the global variables on subsequent s.tl beacons.
For what it's worth, while Mobile Screen Size pulls from user agent and
is wrongly getting lumped into 320x480... "monitor resolution" still
in the browser, and seems to still be correct. I believe this only works
@aahardy That would be slightly better, but the problem is that users
are often on another tab (or off grabbing some coffee or something)- if
they're inactive for long enough to auto-logout, they're probably not
going to be there for the warning either.
Unfortunately, the Adobe Media Analytics extension does nothing more
than set up the heartbeat code and instances.... it does nothing to
actually track anything, and the documentation is SEVERELY lacking. 😕
It'd be great if when _satellite.setDebug(true) were enabled, you would
get additional information about the _satellite.track functions and
Custom Events that are firing. I described an external workaround/fix in
a blog post (Enhanced logging for Direct Call Rules and Custom Events
for Launch/DTM - 33 Sticks ) but basically, right now for a Direct Call
Rule I can either know it fired, or its string wasn't found as a Direct
Call Rule trigger:But now that folks can send extra params with more
That makes sense. But most of the time, extension upgrades do not
directly affect any of the things users are asking the extension to do-
they're for bug fixes, or minor UX enhancements, etc. For instance, if
I'm on Adobe Analytics Extension 1.7.2, and set prop7 to some value in
one rule, then upgrade to 1.7.4 and set prop7 in some other rule... the
fact that one change was made on one version and the other change was
made on a newer version matters nothing to me as a user (though I get
that it ...
Ideally, it would inherit whatever protocol I have on my overall
library- so if I leave it "//", they are all that way, whereas if I
specify "https://", they'd all be https.... though as a developer I know
that's not a simple option.Alternatively, if I could specify in the
Launch interface for my adaptor that I want it to be https, that would
Something that was a potential security concern in DTM is become a
breaking defect in Launch. If I have a page that doesn't load on the
typical "http" or "https" protocol, I would need to specify a protocol
in my embed code, so this:Would become
this:In DTM there is a
potential security flaw with this, where it will load my main file as
HTTPS, but any of the other files (like my appMeasurement library) get
loaded as HTTP. (You can see this on Testing Launch Utility if you load
the page as "http"...
Currently, when you upgrade an extension, you get this notice:This has
scared quite a few clients off of upgrading, because there really is NO
going back. Especially for Adobe extensions, there is a strong need to
be able to revert in case of issues (not to be snarky, but
appMeasurement/VisitorID code updates have a history of finding major
problems in the first month after release). Issues like Re: What are
possible reasons why ClearVariable fails? make it clear why someone may
want to move bac...
Yes, this has come up for a client of mine as well- for instance, if
most of their site can be akamai-hosted, but a portion HAS to be
self-hosted (for security concerns)- ideally they could reference one
production environment through multiple methods.
It'd be wonderful to have a console code snippet (similar to DTM's
"localStorage.setItem('sdsat_stagingLibrary', true)") or even have it
added to the Launch Switcher plugin (which currently requires the user
navigate to Launch's Environments page).Use case: if we want a third
party to be able to test their tag is firing correctly before we publish
it.... they don't have access to our launch, nor to our lower
environments. in DTM I could just tell them "use this snippet and reload
the page", but ...
I suspect Adobe is going to leave this open for someone else to develop-
the joy of an open source system is everyone can wait for someone else
to build it. In truth, 33 Sticks was working on making such a thing
(similar to our existing pixel loader extension) when we realized it'd
probably be better for it to come from a product company, or for folks
to build extensions privately for their own org.
As a followup, I just retested this.... and it is still a problem. It
doesn't seem to make a difference whether the "subsequent" beacons are
s.t() or s.tl()... my global variables only get set on my initial rule.
It sounds like this is actually a defect (with the analytics extension),
based on discussions with the product folks- something to do with the
timing on pageBottom if you are using the Experience Cloud ID service. I
believe it's been communicated to the folks in charge of that extension
so hopefully there will be a fix before long.
Currently, if there is no library assigned to a dev or staging
environment, it 404s. This can (reasonably) bother developers and break
analytics testing on dev/staging/QA servers.Ideally, if an environment
does NOT have a library currently on it, it would just use whatever is
currently upstream in prod.
jen.lasser Alas, I have some followup- I'm doing a training on Wednesday
and have given a training account the same sorts of access/rights that
my users will have, so we see the same things. And now I see that
without fuller rights to Virtual Report Suite admin, I don't even GET
the "add new component" tick box-This is what our users-in-training will
all see when I have them create a new calculated metric. It's icky
enough, I'm going to give up on using the VRS for now:(