This is more a theoric question then a programming one.
Adobe DTM allows to set a "multiple-domains" list in the property settings and it seems to transfer Visitor Data from the main domain to those added.
I wish to know what practical consequence this settings brings.
How Adobe Sitecatalyst then would know that the Visitor and his data are the same?
The "multiple domains" option actually doesn't affect your visitor tracking. It does affect the cookies DTM itself might set (like if you have a persisting data element), and it changes what options you have if you choose "domain" as a condition in a rule.
For visitor tracking across domains, it all depends on your tracking set up. DTM can help set up that tracking (like setting up the Marketing Cloud ID service tool, or setting s.trackingServer) but DTM isn't tracking the visitor directly- it's just hosting the code (visitor ID service and/or analytics appmeasurement code). Check out https://marketing.adobe.com/resources/help/en_US/mcvid/mcvid_cname.html for more info on cross-domain tracking (which is not a concept unique to DTM- as I said, DTM is just the deployment mechanism).
Related
I was trying to submit my addon (source code) about search engines to Edge addon store.
I got denied. The reason they gave me is:
Critical Validations 1 failure(s)
Product Policies
1.1.8 Distinct Function & Value; Accurate Representation
The extension inappropriately replaces the default search engine with that of a third party. You must be the owner or employee of the third party to do so.
I have questions about
1.
The extension inappropriately replaces the default search engine
My addon doesn't change any browser settings. Won't change default search engine. It just gives user more options to use other search engines.
2.
You must be the owner or employee of the third party to do so
My addon provides convinience for user to use Google/Bing/Duckduckgo etc. multiple search engines.
Of cource I don't own Google/Bing/Duckduckgo. My addon provide convinience for your browser users. And it provides way to let user add any search engines they like as shortcut (user using JSON).
Why Edge denies such a tool? It's a tool that sends GET/POST requests, which is what browsers do when user want to search online.
You can find the full policy at https://learn.microsoft.com/en-us/microsoft-edge/extensions-chromium/store-policies/developer-policies
It states:
Your extension must not, without appropriate user consent, alter, or appear to alter, browser functionality or settings including, but not limited to: the address bar search provider...
Apparently, Microsoft thinks changing a dropdown is not an appropriate user consent, or it is not clearly mentioned in the app description as required:
Any alteration to the browser settings should be explicitly documented in the description of your extension.
Also, the policy clearly states you need to be the owner or employee of the search engine:
Your extension may only revise key settings to replace a Microsoft webpage or service with that of a third-party (such as require use of a third-party search engine or set the home page to a third-party web property) if you are employed by or otherwise associated with such third-party.
I think they don’t want anyone else than the owner to build extensions in name of third parties to avoid trademark issues or possible extensions with duplicate functionalities.
I understand this is disappointing after all your hard work, but that’s the risk of building extensions I’m afraid.
This question may seems odd but we have a slight mixup within our Report Suites on Omniture (SiteCatalyst). Multiple Report Suites are generating analytics and it's hard for us to find which site URL is constituting the results.
Hence my question is, is there any way we can find which Site is filling data within a certain Report Suite.
Through this following JS, I am able to find which "report suite" is being used by a certain site though:-
javascript:void(window.open("","dp_debugger","width=600,height=600,location=0,menubar=0,status=1,toolbar=0,resizable=1,scrollbars=1").document.write("<script language=\"JavaScript\" id=dbg src=\"https://www.adobetag.com/d1/digitalpulsedebugger/live/DPD.js\"></"+"script>"));
But I am hoping to find the other way around that where Report Suite gets its data from within the SiteCatalyst admin.
Any assistance?
Thanks
Adobe Analytics (formerly SiteCatalyst) does not have anything native or built in to globally look at all data coming to see which page/site is sending data to which report suite. However, you can contact Adobe ClientCare and request raw hit logs for a date range, and you can parse those logs yourself, if you really want.
Alternatively, if you have Data Warehouse access, you can export urls and domains from there for a given date range. You can only select one report suite at a time but that's also better than nothing, if you really need the historical data now.
Another alternative is if your sites are NOT currently setting s.pageName, then you may be in some measure of luck for your historical data. The pages report is popped from s.pageName value. If you do not set that variable, it will default to the URL of the web page that made the request. So, at a minimum you will be able to see your URLs in that report right now, so that should help you out. And if you define "site" as equivalent of "domain" (location.hostname) you can also setup a classification level for pages for domain and then use the Classification Rule Builder and a regular expression to pop the classification with the domain, which will give you some aggregated numbers.
Some suggestions moving forward...
I good strategy moving forward is to have all of your sites report to a global report suite. Then, you can have each site also send data to a site level report suite (warning: make sure you have enough server calls in your contract to cover this, since AA does not have unlimited server calls). Alternatively, you can stick with one global report suite and setup segments for each site. Another alternative is to create a rollup report suite to have all data from your other report suites to also go to. Rollup report suites do not have as many features as standard report suites, but for basic things such as pages, page views, it works.
The overall point though is that one way or the other, you should have all of your data go into one report suite as the first step.
Then, you should also assign a few custom variables to be output on the pages of all your sites. These are the 4 main things I always try to include in an implementation to make it easier to find out which sites/pages are reporting to what.
A custom variable to identify the site. Some people use s.server for this. However, you may also want to pop a prop or eVar with the value as well, depending on how you'd like to be able to break data down. The big question here is: How do you define "site" ? I have seen it defined many different ways.
If you do NOT define "site" as domain (e.g. location.hostname) then I suggest you pop a prop and eVar with the domain, because AA does not have a native report for this. But if you do, then you can skip this, since it's same thing as point #1
A custom prop and eVar with the report suites(s). Unless you have a super old version of legacy code, just set it with s.sa(). This will ensure you get the final report suite(s), in case you happen to use a version that uses Dynamic Account variables (e.g. s.dynamicAccountList).
If you set s.pageName with a custom value, then I suggest you pop a prop and eVar with the URL. Tip: to save on request url length to AA, you can use dynamic variable syntax to copy the g parameter already in a given AA request. For example (assuming you don't have code that changes the dynamic variable prefix): s.prop1='D=g'; Or, you can pop this with a processing rule if you have the access.
you can normally find this sort of information in the Site Content-> Servers report. There will be information in there the indicates what sites are sending in the hits. Your milage may vary based on the actual tagging implementation, it is not common for anyone to explicitly set the server, so the implicit value is the domain the hit is coming in from.
Thanks C.
I want to associate multiple sitemaps to mvcsitemapprovider during session_start event as sitemaps names and locations are retrieved based upon the type of client/user. But, according to documents related to mvcsitemapprovider, all *.sitemaps are getting associated to mvcsitemapprovider during application start. Is there any way, I can provide this functionality using this control?
There is no built-in per session functionality, but you could implement your own ICacheProvider to handle this requirement. Also see MvcSiteMapProvider 4.0 - Extending the Cache and Multiple SiteMaps in One Application for more guidance.
Do note that the primary reason this doesn't exist out of the box is because it would be extremely memory intensive and would not scale to very many users. Unless your navigation is completely different per user, I wouldn't recommend using this approach. A better alternative is to use the preservedRouteParameters approach to force some route values to match any value (in your case userid or clientid), and then use ISiteMapNodeVisibilityProvider, SiteMapTitleAttribute, and/or manual updating of SiteMapNode properties per request to control the visibility of the node.
Please see my open question here and explain to me why you would want to do this on GitHub, as it renders most of the features useless: https://github.com/maartenba/MvcSiteMapProvider/issues/16#issuecomment-22229604
i've used contentproviders with DB.it has some data in it.i need to make those data available to all other applications.How? Usually the main use of content provider is to store and retrieve data and make it accessible to all applications. They’re the only way to share data across applications; there’s no common storage area that all Android packages can access.I used the code from below link..
http://ashwinrayaprolu.wordpress.com/2011/03/16/custom-content-provider-in-android/
Distribute your Content URI and define your API.
Provide the string of your Content Authority and the paths you recognize. Explain to your users how the tables in your DB map to your paths. Document what the columns in your tables are. Users with your content URI can read and write your databases using standard calls to ContentResolver and the insert/delete/update/query calls.
Provide access control in your <provider> tag in your AndroidManifest.xml. Look at The documentation especially with regard to android:exported, android:grantUriPermissions, android:permission, android:readPermission and android:writePermission. You'll need to decide how to use those based on your use cases. Also, the <grant-uri-permission> tag will give you even more fine-grained control.
Write other apps to use those calls you just documented and allowed permissions for.
I am new to JIRA.
Can somebody explain to me the meaning of the different schemes in JIRA; like issue security scheme, notification scheme and so on?
Helpful online resources are also highly appreciated.
A notification scheme maps email notifications to various events. For example: "When a defect is assigned, send an email to the assignee."
A Field Configuration Scheme maps Field Configurations to issue types.
A Screen Scheme allows you to choose which Screen will be shown to a JIRA user when they perform a particular issue operation.
An Issue Type Screen Scheme associates a Screen Scheme with issue types,
An Issue Security Scheme determines who can and cannot see issues.
A Field Layout Scheme allows you to configure which fields are visible and/or required fields for a given issue type on a per project basis.
For more details, check the Jira documentation.
I really appreciate the detailed explanations available at "The Grey Blog":
http://thegreyblog.blogspot.com/2010/11/atlassian-jira-configuration-tutorial.html
Most parts of JIRA configuration can be set up differently for different projects. Some things, like custom fields, can be also set up differently for any pair of (project, issue type).
The schemes are the means to configure these per-project/per-type configuration pieces, with probably reuse of one configuration among different projects.
For example, issue security feature allows you to set up options for Security Level field and limit issue visibility to certain users based on the value of that field. Issue Security Scheme contains definitions of those options and how they limit issue visibility.
So you first configure Issue Security Scheme (may be more than one) to define that piece of configuration, and then you can assign each project one of the available Issue Security Schemes (or neither one), thus applying those pieces of config to the issues in that projects.
Jira enables flexibility to customize issue types, fields, workflows, screens, permissions, security and notifications through schemes. You can create, assign and reuse these schemes to your projects based on your needs. These schemes are assigned to project's related schemes like plug and play.
Notification scheme -- You can configure notifications like email for the issues you create or issues assigned to you and any change in status
Field Configuration scheme -- Scheme used to configure fields.. You can set based on project. You can add more fields and add to particular scheme. You can even set restrictions (lets say if it is mandatory field or not)
Permissions scheme -- Used to set permissions for the project. You can name like Admin or general user and give what they can do
Screen scheme -- Used to add fields for a particular screen.
While others answered most of the points, I would like to throw some light on Issue Security Scheme.
This is the most versatile scheme where you can restrict accessing certain issues by the security level user has.
With combination of the permission groups and issue security features, you can do almost anything in Jira from a workflow point of view.
Well schemes are sort of mapping entities.
They contain the units, like workflows,screens,issue types.
Schemes will define how a project decides which unit to use for which issue/operation.
This is of course a high level explanation.
Best bet is to start experimenting with 1 scheme, let's say screen scheme. Once you get the hang of the scheme entity, every other scheme will become understandable.