@Brian_Kent_Watson , firstly, your answer is incorrect.Secondly, it's
extremely rude to just dismiss a popularly used project which extends
the capabilities of Analytics both furthering its adoption and picking
up the slack where Adobe didn't bother to spend the resources.
Hi @prathap08 , It depends on what API they need access to as some v2.0
don't work w/o OAuth and System Admin permissions... However, if all
they are doing is exporting/inserting data, they don't need anything
more than being a developer on a PP with their report suite.
Furthermore, there's pretty much no reason to have product profile
admins. The only times those are necessary are for products like Target
where customizing permissions either requires being a product admin or
profile admin. This...
Users have been requesting that many of the missing Report Suite/Admin
API (v1.4) become available in the I/O Console (as v2.0 API). In
particular, many users would benefit from exporting the mapping of
processing rules, as suggested here.Is this something that is on the
road map for Analytics API development?
Something else to note: If Analytics API is already added to a project,
it will no longer display. If the Analytics API is missing the correct
permissions (using JWT auth), it needs to be removed and re-added with
any additional product profiles.
We have teams within my organization that would like to manage the
creation and distribution of curated report suites/virtual report
suites, but currently the VRS section of Analytics is reserved for
admins, ref. Can this section get its own dedicated Analytics (Report
Tool) permission so that this is possible without introducing the
vulnerability of a team of new admins?
Hi @prathap08 , It depends on how much control over their own
integration you want to share with that team. You have roughly four
options:1. For v1.4 API (which is completely tied to that user's
login/permission scope), you need to give them "Web Service Access"
through some AA product profile. Then provide the user their credentials
from Analytics > Admin > All Admin > Web Services.2. Give them full
"Developer" permissions within the Admin Console (under Users >
Developers). This lets them setu...
Yea, but I doubt the average user would be okay with a million popups
for every bit of blocked traffic. Most major sites use multiple tracking
mechanisms where a user would get a list of blocked tracking every time
they navigated to a new page. If this is something you suspect will be
an issue moving forward, now might be the best time to begin work on an
in-house tracking solution that is server-side. Though the data itself
can be stored and reported from Adobe if you forward it to them. I
Ah, yea, it sounds like there isn't much you can do to get around this.
Do many of your users actually use this blocking list? The only possible
ways I can think of to get around this would be to either have Adobe
modify their tracking servers (and subsequently the Launch code)--not
very likely, or, the only thing that you could maybe do on your side,
review the different methods for data insertion API and see if the those
formats are on the block list. If not, you could integrate that API into
@pramseycom , good find. Sounds like a clever blocking list. Luckily,
you can actually create whatever CNAME records you want, as long as they
resolve to Adobe's host. Maybe just come up with an uncommon naming
convention and distinguish between secure/non-secure protocol.
If the issue is an Adobe-blacklist you should look into first-party
tracking--unless your IP is also on a blacklist.Also, if it is blocking
Launch/DTM code, you can host your own versions instead of using Akamai.
This sounds like a stale login cookie.You should try having the user
clear their Adobe-set cookies and login from scratch. This often happens
if significant changes in permissions have happened to the account or if
they haven't used AA for a long time without signing in.
Within Analytics, there are ways to configure sensitive data through the
Admin > Data Governance section. Some solution dimensions don't appear
within this section. In particular, I'm not finding any of the Ad
Parameters (e.g. a.media.ad.creative which is ultimately reported
through "Creative ID"). Is there a way to set up governance around these
solution dimensions similar to other solution dimensions?
Hi @balakrishnad200 , Please see the the post here for a deeper
explanation of clearvars().Variable expiration can be set within the
Report Suite Mgmt admin section, and you can set the expiration to be on
a hit (effectively making it a prop). Depending on your business
requirements, it might be sufficient to just use a prop (or hit-level
expiration variable). The main point of having variables persist are to
help determine which actions on your property are leading up to a
success even (in this...
@saumgupt, thank you for your help related to v1.4 API, but please stop
defending your incorrect answer.You are not addressing the original
question.Furthermore, several of the requested APIs are not available
using v1.4 API either, such as usage logs which was v1.3 and
viewProcessingRules which they are claiming should not be public facing,
@saumgupt, this is an incorrect answer:Firstly, this question is about
v2.0 API not v1.4 API which all of your links refer to.Secondly, WSSE
authentication has not yet been deprecated for v1.4 API.The reason
behind this question is to determine which of these API will still be
available within the v2.0 API after these become deprecated.
Hi @derroque , There is a workaround that my team is going to start
using to better delegate the sharing of components (e.g. segments,
calculated metrics). Normally we would create a user group and assign a
user group admin where access to the group would give access to the
components, but in this case, we will suggest to the user that would
have been the admin to create a single utility Workspace report that has
all of their team's components brought into it, and they will be
responsible for sh...
Hi @LukeAhn , can you confirm this is true for user groups? I am both a
system admin as well as an Analytics product admin and the only options
available to my organization are sharing with individual users, "ALL",
or specific product profiles.
There is an idiosyncrasy with Analytics were assets can only be shared
with individual users, the whole organization, or specific product
profiles. However, the Admin Console is designed to use user groups as
the method of grouping users and product profiles as grouping permission
levels. So if common permissions are shared across an organization,
there is no convenient way of sharing work without sharing with
everyone. Thus it makes sense to share assets just with groups of users
rather than gr...
Hi @FrankJansen , There's actually a current idiosyncrasy (bug, imo)
with Analytic's share features due to the integration of the Admin
Console. Many assets (projects, segments, etc.) can only be shared with
individual users or, if a product admin, with product profiles. So even
if user groups are defined within the Admin Console, they cannot be
selected to share content. So unless each group of users is defined
under their own product profile, sharing this content will be accessible
@aliskink1 , This could be happening at different levels of your org,
ref.And though it could still be a glitch on Adobe's side, there is a
lot of opportunity for user error/misuse.You will need to involve a
system admin from your organization, as it really is their
responsibility to get to the bottom of this issue. But they will need to
take the following troubleshooting steps:Check if the affected account
still exists within the Admin Console or if it was just permissions that
are modified.If ...