I've setup an experiment on a specific URL in which I send no traffic
(same domain name that I use for other landing pages but with different parameter in the URL)
I've started the experiment few days ago without sending any traffic
And now I see that the experiment got triggered around 5000 times.
I double checked on my analytics reports and I see no access to the main page that is supposed to trigger the test. To explain with example:
This is what I have running:
http://domain1/landingpages?id=1
http://domain1/landingpages?id=2
this is the test that I created:
http://domain1/landingpages?id=3
with a 50% redirect on:
http://domain1/landingpages?id=4
The Experiment should only be triggered on id=3 page, but it did got triggered with id=1 and id=2 pages. Any idea how I can make the trigger only happen when "id=3" is in the url ?
Currently my configuration is as follow:
"WHEN Url Matches "http://domain1/landingpages?id=3" "
The URL targeting documentation explains your situation. (Emphasize by me.)
Use matches when there are query string parameters in URLs that you
don’t want to include in the matching. Matches can be more flexible
than equals because it adheres to the following rules:
Ignores query string parameters and fragments.
Case insensitive.
Normalized to remove a www. prefix.
Normalized to a remove a trailing slash.
HTTP and HTTPS are optional (HTTP will match HTTPS).
Verifying this in Optimize:
So you should either simply select Equals operator and use http://domain1/landingpages?id=3 as a value.
If other parameters might occur, then you could build a regex for this, to containt id=3 among various parameters. E.g.:
http:\/\/domain1\/landingpages\?(.*&)?id=3(&|$)
Optionally, you can use Query parameter targating, and build a rule for the base URL, and for the id parameter separately.
Related
A.S/ probably for another SE.com site: why "referer" is spelt with only r at Google's?
Anyway, here we go again with another occurrence of RefererNotAllowedMapError.
I couldn't find my answer in the existing Q&As.
Hypothesis:
I have a local website that includes a GMap.
It displays and works
fine provided I remove all restrictions on that key, from the Google
API console.
But the browser will receive a Google Maps JavaScript
API error: RefererNotAllowedMapError whenever I add a referrer
restriction, which seems to match the refering URL.
The referrer, where the map is being called form, is:
https://app.developr.online.local/projects?p=name-asc-0-20-1&a=createProject
Below is my GAPI KEY security configuration:
Below is the corresponding console output:
To be noted:
If I add a trailing asterisk when declaring the referer, validating that entry will clear it anyway. To me it means: "that's ok, we're covering trailing /* already.".
My question: what pattern should I enter as a referrer (2 r's) to have it recognised by GAPI security layer?
I've tried a few things, I didn't get a cigar.
Thank you.
I'm trying to filter on AppDynamics to get all the request to a particular REST URL, the REST URL is not fixed as long as in the URL
/AppEngine/rest/evac/${id}/createNewActivity
On the Transaction Snapshots you have the option to filter results, and in the filters you can filter by URL:
If I search for a concrete URL (with ${id} defined) I can search it, but I cannot find how to use a wildcar to find this URL with any ${id}. I tried so far to use
/AppEngine/rest/evac/*/createNewActivity
/AppEngine/rest/evac/.*/createNewActivity
With no results.
The one with works just a bit is using /AppEngine/rest/evac/* which also retrieves other REST which start with the same URL, so I can export the results and filter outside AppDynamics.
But there is a way to use a wildcard so I can find the desired results in AppDynamics?
Even it is not the desired behaviour, if filtering by URL and specifying only createNewActivity worked for me (as long as there are no other REST URLs matching this).
In my Content Drilldown, when I go to the second page path level of one of my domains the link that displays duplicates the domain in the uri.
For example..
If I have the following:
events.company.com/
When I drill down the link above I will get:
/http:/
/
/some-directory/
When I click the Page dimension I will then get these links:
events.company.com/
events.company.com/http://events.company.com/index.php#
events.company.com/http://events.company.com/index.php#view/all
So you'll see that the links above like below is incorrect:
events.company.com/http://events.company.com/index.php#
It needs to be
events.company.com/index.php#
....but I don't why it's coming through like that and how to correct it.
Any suggestions?
Thanks
Actually, seems like someone followed the "right" instructions from GA help:
By default, the data in your reports includes only the Request URI and
not the domain name:
URL of page: http://www.example.com/foldername/page.html
Request URI: /foldername/page.html
Domain name: www.example.com
If you'd like to see the domain name as well as the Request URI in
your reports, create an Advanced filter for your view with the
following settings:
Filter Type: Custom filter > Advanced
Field A: Hostname
Extract A: (.*)
Field B: Request URI
Extract B: (.*)
Output To: Request URI
Constructor: $A1$B1
Note that creating URL rewrite filters like the one described above
can affect Analytics' ability to match your goals properly.
If you're using Analytics filters to rewrite your URLs, you need to
make sure that your goal settings reflect these changes. Like all
filters, URL-rewrite filters are applied to the raw data coming into
your account, before goals are processed. As a result, your goal and
funnel URLs should reflect the final, rewritten format of the URL.
https://support.google.com/analytics/answer/1012243?hl=en
However, it does messes data quite a lot. I believe this is an issue with GA, at least this documentation is misleading. Such filter also affects URL matching on Goals and funnels, so I would not recommend it.
On my site I am tracking the URL /shop/ as goal by head match. As there are some URL parameters I cannot use exact match here.
Additionally, I am tracking a goal by exact match which is a URL to subfolder: /shop/process/paid.php
The problem is that GA tracks this subfolder with the head match as well, and thus saves the URL parameters that come along with paid.php, e.g. paid.php?email=customer#home.com
How can I prevent GA to track the URL parameters?
How would the setup look like?
Thanks!
That should work with a custom filter:
admin->profile->filters->custom filter->search and replace.
Search for
/shop/process/paid.php\?.*
(that's your url with arbitrary query parameters, the "\" is an escape sign since "?" is also an control character in regular expression. Dot means any character and "*" means any number of the preceding (in that case any) character) and replace with the desired url ( /shop/process/paid.php).
There is probably a more elegant solution but like most people I'm not good at this regex stuff. This should work however.
Alternatives:
If those query parameters are nowhere needed in the tracking data you can exlude them completely in the profile settings.
You can created a profile for the subdirectory based on the directory (include filter->request uri contains "/shop" and set only this profile to remove query parameters
-I'm using a number of WordPress rewrite rules to allow for the injection of country-codes immediately at the beginning of the URL path, which are used to determine a timezone offset. An example:
add_rewrite_rule('^([A-Za-z]{2})/days/([0-9]+)/?$', 'index.php?geo=$matches[1]&m=$matches[2]&post_type=days','top');
This takes a request like www.daysoftheyear.com/days/2011/ (which would usually return all valid content for this request) and allows for, e.g., www.daysoftheyear.com/us/days/2011/ to return the same content but with support for a timezone offset based on the country-code.
This works fine in almost all places, with the exception of a single query type - one for 'days' custom post type pages, e.g., http://www.daysoftheyear.com/days/waffle-day/.
The rules I have in place are:
add_rewrite_rule('^([A-Za-z]{2})/?$', 'index.php?geo=$matches[1]','top');
add_rewrite_rule('^([A-Za-z]{2})/days/([0-9]+)/?$', 'index.php?geo=$matches[1]&m=$matches[2]&post_type=days','top');
add_rewrite_rule('^([A-Za-z]{2})/days/([0-9]+)/([0-9]+)/?$', 'index.php?geo=$matches[1]&m=$matches[2]$matches[3]&post_type=days','top');
add_rewrite_rule('^([A-Za-z]{2})/days/([0-9]+)/([0-9]+)/([0-9]+)/?$', 'index.php?geo=$matches[1]&m=$matches[2]$matches[3]$matches[4]&post_type=days','top');
add_rewrite_rule('^([A-Za-z]{2})/days/([A-Za-z\-].*)/?$', 'index.php?geo=$matches[1]&page=$matches[2]','top');
add_rewrite_rule('^([A-Za-z]{2})/([A-Za-z\-].*)/?$', 'index.php?geo=$matches[1]&pagename=$matches[2]','top');
The fifth rule shoud match http://www.daysoftheyear.com/gb/days/waffle-day/ in much the same way as above, but redirects - I suspect that it's confliucting with the inbuilt rules which attempt to redirect to a correct URL if it's malformed (e.g., if I type a close structural match to a correct URL, it'll redirect me to the correct resource).
I can confirm that the 'raw' URL for this request works - e.g., http://www.daysoftheyear.com/index.php?geo=en&name=soup-month&post_type=days returns a valid and expected result.
I'm not convinced this is a regex rule, rather than a specific challenge with the way WP manages custom post types?
EDIT
Updated to allow for hyphens - no change in behaviour, though regexpal reports that the regex works against the example URL.
Updated after disabling WP canonical redirects functionality - now 404'ing rather than 301'ing to the page.
Updated to use 'page' rather than 'pagename', based on the information here: http://codex.wordpress.org/Class_Reference/WP_Query#Post_.26_Page_Parameters - no change in behaviour.
Updated the code, added a linebreak and clarified that I'm actually referencing line 5, rather than line 4.
This request http://www.daysoftheyear.com/days/waffle-day/ won't match your fourth rule since you didn't allow - inside the group cature : ([A-Za-z].*). Replace this group with ([A-Za-z\-].*) and it should match.
HTH
Resolved; it appears that the above ruleset now works correctly - thanks all!