I am trying to port this javascript version of GA to native iOS SDK
pageTracker = _gat._getTracker("UA-XXXXXXX-1");
pageTracker._setDomainName(".test.org");
pageTracker._trackPageview();
I know how to set the UA account and how to report a pageView, but how do I set the domain name ?
[[GANTracker sharedTracker] startTrackerWithAccountID:#"UA-XXXXXXX-1"
dispatchPeriod:kGANDispatchPeriodSec
delegate:nil];
if (![[GANTracker sharedTracker] trackPageview:#"/"
withError:&error]) { // Handle error here }
Just following up from my comments. You don't need domain in the Google Analytics native code tracker for iOS. It's used on the web so you can track traffic at a more granular level on sites where multiple sub-domains might be used. For example, if you have a generic "Products" web page, but the same Products page lives on dogs.mystore.com/products and cats.mystore.com/products, and you want to use the same tracker but differentiate the traffic between those two sites, you can leverage the domain variable in the Javascript API. I can't think of a use case like this where it would be needed behind a native app.
Here's a reference for it related to the JavaScript API
https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingSite
Bottom line, it's not needed. :)
Related
I know the current Google Sites API only supports Classic Sites.
Does this API exist now? and How to manage(create and etc) New Google Sites though API?
No, an API doesn't exist.
There are several feature requests in the issuetracker.google.com site, so they are aware it is needed. You would think they have some of the framework developed, since there is currently some access to sites (and I don't mean for editing) through the existing drive API. It would be worth adding your comments to those requests in the issue tracker website.
https://issuetracker.google.com/issues/36761330
https://issuetracker.google.com/issues/7324991
https://issuetracker.google.com/issues/120462223
https://issuetracker.google.com/issues/205856782
Though Google Sites API is still not available, I discovered some good news (for my use case, at least). I can confirm there are some minimal Google Sites abilities available through the Google Drive API. Specifically, I was able to add a user to the my site as viewer to a published site, using the Drive API permissions. Here is the Python code.
# get boilerplate creds= code from here https://developers.google.com/drive/api/quickstart/python
drive = build('drive', 'v3', credentials=creds)
new_permission = {
'type':'user',
'role':'reader',
'view':'published',
'emailAddress':USER_EMAIL
}
# you can get the SITE_FILEID from the site url
res = drive.permissions().create(fileId=SITE_FILEID, body=new_permission).execute()
Since the OP specifically asked about create, that works like so:
new_file = {
'name':'test site2',
'mimeType':'application/vnd.google-apps.site',
}
res = drive.files().create(body=new_file).execute()
Hope this can help some folks.
If you check Google sites api at the very top of the page it states.
If there was an api for accessing the new version they would have stated it. There is not.
According to this question, Google planned the new API for Google Sites for end of 2021: https://support.google.com/sites/thread/3363462/is-there-any-eta-for-the-new-google-sites-api?hl=en
I did not hear any news, since that.
Experience cloud vistor id is used. App, web are using same adobe launch library. When I login into app url change and mid changes and then if I navigate from app to web responsive page mid is changed and I am not seeing any cross-domain pathing report from app to web ?
anything do I need to do with s.cookiedomainperiod or anything to make this work?
The Experience Cloud Visitor ID is not automatically carried over from the native mobile app to a (mobile) web page. The long story short is native apps don't really store data locally in the same way as web browsers, so there's no automatic ability to use the same local storage mechanism/source between the two.
In order to do this, you must add some code to the mobile app to append the mid value to the target URL, e.g. :
Android
String urlString = "http://www.example.com/index.php";
String urlStringWithVisitorData = Visitor.appendToURL(urlString);
Intent browserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse(urlStringWithVisitorData));
startActivity(browserIntent);
iOS
NSURL *url = [NSURL URLWithString:#”http://www.example.com/index.php"];
NSURL *urlWithVisitorData = [ADBMobile visitorAppendToURL:url];
[[UIApplication sharedApplication] openURL:urlWithVisitorData];
If implemented properly, you should now see a adobe_mc= parameter appended to the target URL. Then on page view of the target page, if you have the Adobe Analytics javascript and Experience Cloud Visitor ID libraries implemented, they will automatically look for and use that value instead of generate a new value (should not require any config / coding on this end).
Update:
#Ramaiyavraghvendra you made a comment:
Hi #Crayon, mny thanks for your profound answer. I am sorry that i
missed to inform that this app is not native one but this is a SPA
app. so the implementation of entire app is also done through launch.
Could you pl help in this case then.
I'm not entirely sure I understand your issue. If you are NOT moving from a native mobile app to web page, and your mobile app is really a web based SPA that outputs Launch as regular javascript code throughout the entire app, then you shouldn't have to do anything; the Experience Cloud ID service should carry over the id from page to page.
So it sounds to me like perhaps your Experience Cloud Visitor ID and/or Adobe Analytics collection server settings are not configured correctly. the cookie domain period variables may be an issue, if logging in involves moving from say www.mysite.com to www.mysite.co.uk or similar, but shouldn't be a problem if the TLD has the same # of periods.
Or, the trackingServer and trackingServerSecure variables may not be configured properly. In practice, I usually do not set trackingServerSecure at all. These variables get kind of confusing and IMO buggy in different scenarios vs. what you are using, so I tend to use the "secure" value in the trackingServer field and leave the trackingServerSecure blank, and then Experience Cloud Visitor ID and Adobe Analytics will just use the secure version 100% of the time.
Or..it could be a number of other config variables not properly set. It's hard to say if any of this is off, without access to the app and Launch container.
Also you may want to check the response headers for your logged in pages. It may be that they are configured to reject certain existing non-https cookies or something else that effectively causes the existing cookies to be unreadable and make the Experience Cloud ID service generate a new ID and cookies.
Or.. maybe your app kind of is a native mobile app but using an http wrapper to pull in web pages, so it is basically a web browser but it is effectively like moving from one web browser to another (e.g. starting on www.site.com/pageA on Chrome, and then copy/pasting that URL over to Internet Explorer to view). So effectively, different cookie jar.
Launch (or DTM) + Experience Cloud ID (Javascript methods)
In cases such as the last 2 paragraphs, you have to decorate your target links the same as my original answer, but using the Launch + Experience Cloud ID Service javascript syntax:
_satellite.getVisitorId().appendVisitorIDsTo('[your url here]');
You write some code to get the target URL of the link. Then run it through this code to return the url with the parameters added to them, and then you update your link with the new URL.
Super generic example that just updates all links on the page. In practice, you should only do this for relevant link(s) the visitor is redirected to.
var urls = document.querySelectorAll('a');
for (var i = 0, l = urls.length; i < l; i++) {
if (urls[i].href) {
urls[i].href = _satellite.getVisitorId().appendVisitorIDsTo(urls[i].href);
}
}
I've been following the guidance on google to create a PWA, but I am interested if there are any conventions to communicate with your data server that you are being called by a PWA. Is the easiest thing to add a parameter to the request i.e.
var dataUrl = 'https://query.myapi.com/v1/get?source=pwa';
and then check the source parameter? Or should I add to the request header?
In your code
if (window.matchMedia('(display-mode: standalone)').matches) {
// do things here
// set a variable to be used when calling something
// e.g. call Google Analytics to track standalone use
}
** Assumption made that you are also setting up your app to be added to the users home screen as a shortcut
You have to pass in the traffic source to Google Analytics indicating its from PWA. Refer this answer on more details.
The Facebook SDK has the ability to record both custom events and standard events. The standard events are things like "Purchases" "Add to cart" "Completed Registration" etc...
Recording these standard events gives you access to specific bidding features on Facebook ads that you don't get without the events.
I have an app that has the React Native FBSDK
There are two methods for defining an event - one for purchases and one for everything else as seen here
There is zero documentation for standard events on react within the SDK on Github or on the event tracking docs on Facebook's developer platform.
Right now I'm trying to track the standard events by using their various names, as recorded across FB's documentation. I've tried the following:
AppEventsLogger.logEvent('FBSDKAppEventNameCompletedRegistration');
AppEventsLogger.logEvent('CompletedRegistration');
AppEventsLogger.logEvent('Completed Registration');
All of these just create custom events with those names, but aren't recognized as standard events.
Has anyone gotten standard events to work using the React Native wrapper for the FB SDK? If so how do you name the events to get FB to recognize them?
Update: As the comment below highlights, the more recent link is https://developers.facebook.com/docs/marketing-api/app-event-api/
It looks like you'll have to pass the strings that those standard events get evaluated to, i.e. instead of 'FBSDKAppEventNameCompletedRegistration', you'll have to use: 'fb_mobile_complete_registration'.
Here's the source:
Sorry if this is a bit late. Hope this helps.
I managed to find the actual event name by generating standard event code using tool on Facebook's documentation, run the code in AppDelegate.m, and get the exact key-values from Events Manager. With this roundabout way, I realized the actual name of Add to Cart event was fb_mobile_add_to_cart. From there I googled for the name and found the list documented in Marketing API (why not App Events?).
I don't know if it is the right place, but you can refer to https://developers.facebook.com/docs/marketing-api/app-event-api/ for actual standard event names and parameter names. At least it worked in my case. Here's my Add to Cart event code:
function logAddToCart(totalPrice, contentType, contentId, currency) {
const params = {
'fb_content_type': contentType,
'fb_content_id': contentId,
'fb_currency': currency
};
AppEventsLogger.logEvent('fb_mobile_add_to_cart', totalPrice, params);
}
I made a simple package with all events. Just import like
import FBEvents from "react-native-fbsdk-events";
// ...
AppEventsLogger(FBEvents.COMPLETE_REGISTRATITON, params);
I need to create Saved Target Group in facebook programmatically like PowerEditor does it here https://www.facebook.com/ads/manage/powereditor.
During inspecting the browser's console when saving through the Power Editor I've discovered that such kind of an endpoint is used:
"https://graph.facebook.com/v2.2/act_#AD_ACCOUNT_ID#/audiences", but the method called is encrypted and there is no information about this kind of endpoint in the facebook API documentation.
Seems like Power Editor uses more extended API or not all the API is well documented.
Did anybody experience something similar?
Thanks
Not all of the functionality available in Power Editor is available in the public API or vice versa -
If what you're asking about is not in the public API documentation, it's not part of the API that is available publicly -
It would be dangerous to assume that an undocumented endpoint will continue to work or that it works in a specific way based on observing another app (Power Editor) calling it
You can use saved_audiences API.
Here is Graph Explorer request examples:
POST:
https://developers.facebook.com/tools/explorer/765026780221012?method=POST&path=act_&Fsaved_audiences&version=v2.5&name=foo&targeting={ "age_min":18, "age_max":65, "page_types":[ "desktop-and-mobile-and-external" ], "geo_locations":{ "countries":[ "US" ], "location_types":[ "home" ] } }
GET ALL:
https://developers.facebook.com/tools/explorer/765026780221012?method=GET&path=act_%2Fsaved_audiences&version=v2.5