The setup
I have an iOS app with a basic Branch SDK integration. All it does is:
reports the install event (via initSession() call)
some time later calls setIdentity() method to identify the user with an ID received from backend
Later inside the app the user is offered a subscription with a trial period. The backend receives a notification once the trial is started. I want to report the trial start from my backend to the Branch (server-to-server way) so it is attributed to the Branch channel/campaign and I can see the efficiency of each campaign inside the "Sources" tool in Branch.
To do this I execute the following curl request in accord with the documentation https://github.com/BranchMetrics/branch-deep-linking-public-api#logging-user-lifecycle-events:
curl -vvv -d '{"name": "START_TRIAL","customer_event_alias": "Trial Start","user_data": {"os": "iOS","environment": "FULL_APP","aaid":"93A6BC61-AC2B-4008-9565-4DF2FD2395C9","limit_ad_tracking":false,"developer_identity": "41740","country": "US","language": "en"},"custom_data": {"product_id": "my.product.id"},"metadata": {},"branch_key": "key_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}' https://api2.branch.io/v2/event/standard
The received answer is:
{"branch_view_enabled":false}
As seen from the request I pass the IDFA and developer_identity and I expect that it would be enough to attribute START_TRIAL event to the Branch channel/campaign, which brought the user.
The problem
The START_TRIALS and other valuable events are attributed to organic traffic. So for a test campaign I see a click, an install an open but zero trial starts. The trial start is attributed to the organic traffic.
What I've checked
I've checked with Charless SSL that the user ID is sent by Branch SDK to Branch backend (notice same IDFA 93A6BC61-AC2B-4008-9565-4DF2FD2395C9 and user id 41740):
"os": "iOS",
"hardware_id": "93A6BC61-AC2B-4008-9565-4DF2FD2395C9",
"screen_width": 750,
"identity_id": "789438365770392069",
"build": "16G183",
"ios_vendor_id": "A3656BAB-CDF9-4572-B944-80D5B6017376",
"hardware_id_type": "idfa",
"instrumentation": {
"/v1/install-brtt": "406"
},
"environment": "FULL_APP",
"model": "iPhone7,2",
"identity": "41740",
So given all of the data I already pass to Branch, what else should I do to merge events sent server-to-server with user installs reported from the client?
If you are trying to track iOS event I guess you should use user_data.idfa instead of user_data.aaid (Android ID).
From documentation:
user_data.aaid : Android/Google advertising id
user_data.idfa : iOS advertising id
Related
I'm looking to implement Google Wallet for digital goods' subscription on my website.
I understand how it works with postback on start and cancellation.
I'm worried if cancellation postback fail contacting my server. As I have a rather large amount of subscriptions, checking manually would be bothersome so I was wondering if there is any way to check subscription state contacting google wallet servers (like Paypal API).
How do you manage failed cancelation postback ?
Thanks,
AFAIK, there is no API to "query" - it would be nice to have :) I recall asking a similar question back in one of Google's developer hangouts about "repurposing" some of the now deprecated Google Checkout API which did have "query apis".
I'd suggest you mitigate things by logging all notifications - aka "notification history". If you experience a processing error on your end, you'd still have access to the "raw data".
Of course this assumes 2 things, (1) Google will never fail sending you a postback, and (2) your server/s are always ready (if they're down, then they can't receive).
Unless I'm corrected by a Googler, I don't believe I've seen a "retry policy" - error on either end - e.g. in GCO API postbacks were resent until the merchant successfully "acknowledges" receipt of the postback. Until then, I think you're down to looking at Merchant Center (manual).
Hth...
How does automatic updates work in passbook available in backfield of the pass, how to use webserviceURL key to get update from the server.
in webserviceURL key i have provided remote path from where updated pass can be downloaded, but even after content changed in server, it does not reflects in pass.
This question has been asked so many times, in so many ways, in so many forums; mostly by people that are too lazy to read the manual, or are too inexperienced / incompetent to understand it.
The first paragraph of the Passbook Web Service Reference explains why simply adding a link to an updated pass will not work.
A REST-style web service protocol is used to communicate with your server about changes to passes, and to fetch the latest version of a pass when it has changed. The endpoints always begin with the web service URL, as specified in the pass, followed by the protocol version number. For example, a request for the latest version of the pass of type com.apple.pass.example and serial number ABC123 might look like the following:
The Passbook web service is an integral part of the Passbook eco system. Anyone wishing to issue passes that change their content (either in response to a push message or in response to a user requesting fresh content by pulling down on the back of the pass), needs to implement their own Passbook web service.
This entails building a server capable of responding to the following to authenticated requests from each device that has installed your pass.
There are 5 methods that your web service should respond to:
1. Registering a Device to Receive Push Notifications for a Pass
POST request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier/serialNumber
2. Getting the Serial Numbers for Passes Associated with a Device
GET request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier?passesUpdatedSince=tag
3. Getting the Latest Version of a Pass
GET request to https://webServiceURL/v1/passes/passTypeIdentifier/serialNumber
4. Unregistering a Device
DELETE request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier/serialNumber
5. Logging Errors
POST request to https://webServiceURL/v1/log
In order to have a pass respond to a manual refresh or push request you need to implement at least the first 3 methods. This is because the device will not issue any further requests until it has received a valid response to the registration request.
Furthermore, the web service must be available over https. An unsecured http service can be used for development, but production devices will only recognise a webServiceURL key that begins with https.
I have questions related pushing messages to a user.
Here is the use-case.
A user is walking inside a wifi enabled warehouse and we would like to use the glasses to send critical information and warnings about the components in that building which required the user to interact with the component(s).
We have used push notifications in android devices with ok results, but with a live hud I would like faster updates.
Basically we will send something like this to the user
{
"html": "<article>\n <section>\n <strong class=\"red\">ALERT </strong>13:10 device ABCD tolerance failure. \n </p>\n </section>\n</article>\n",
"notification": {
"level": "DEFAULT"
}
}
How quickly can we get the information to the device?
What is the update rate? If we see an alert from a machine can, how quickly can we refresh the user of its status.
Is there some type of flood protection that would cause us grief?
I assume native api will have more options, such as polling or some type of custom subscription service which we could use for faster updates than google's service. Is this correct?
Thanks
Nick
This is not something that is expected to be done with the Mirror API. The GDK is where you would want to do this and they are taking feature requests. You might want to add your use case to this thread:
https://code.google.com/p/google-glass-api/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Owner%20Component%20Summary&groupby=&sort=&id=75
To answer some of your other questions:
1 - Mirror API card pushes happen within seconds
2 - Seconds
3 - You are currently limited to 1000 card pushes a day per developer account, so that would be shared across all your users
4 - Curently there is no supported way to do that
As a final thought, if you really want to do this without official support, you could watch this video which shows you how to run "normal" android apk's on Glass. It is a presentation from Google I/O 2013:
http://www.youtube.com/watch?v=OPethpwuYEk
Background:
So I'm a novice to the whole app engine thing: I have made an app on google app engine that on the main page accepts user input and then sends the information to a handler that then uses the Big Query API to run a synchronous query with some tables I have uploaded to Big Query. The handler then sends back the results of the query as a json.
Problem:
In deployment it works mostly except sometimes a user can often run into this error while trying to make the synchronous query:
Error in runSyncQuery:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "termsOfServiceNotAccepted",
"message": "BigQuery Terms of Service have not been accepted"
}
],
"code": 403,
"message": "BigQuery Terms of Service have not been accepted"
}
}
After doing some searching I com across this:
https://groups.google.com/forum/#!msg/bigquery-announce/l0kwVNpQX5A/ct0MglMmYMwJ
If you make API calls that are authenticated as an end user, then API calls will soon return errors when the end user has not accepted the updated Terms of Service. Apps built against the BigQuery API should ideally look for those errors and direct the user to the Google APIs Console to accept the new terms.
Except I dont really understand how to do this.
Also all the potential user accounts that I have tested my app with have access to a specific project that has Big Query API enabled, and can use the API so why does this pop up?
Also there are times when a specific account does not run into this problem. For instance if I keep refreshing and retrying to use the app eventually it will not have this problem and work. But then the next time this error will resurface again.
I don't understand how a user can have accepted the terms of service at one point of time and then not another at some point in the future?
Yes, any end users who authorize access to the BigQuery API must accept the Terms of Service (ToS) provided by the Google Developers Console at https://developers.google.com/console
It is possible that Terms of Service can change, and that some of your project members have not yet accepted updated BigQuery ToS. If one of your users is receiving this message when authorizing access to the BigQuery API, you redirect them to the https://developers.google.com/console to accept the terms of service.
Re: "specific account does not run into this problem" - can you confirm this is happening consistently with a specific account on a specific project?
I've followed the Order Processing tutorial to receive and handle order notifications in my GAE application from Google Checkout.
Everything works OK in the sandbox environment. I can send a fake order and the app gets a notification and handles the order.
When I switch to the production environment and make a real order, I can see the order in the Google Checkout Merchant account but I don't receive any notifications.
To switch to production I simply edit my ApiContext object to use Environment.Production and the real merchant id and key. The Integration settings are the same. I've also tried changing the callback URL to use HTTPS (https://blah.appspot.com/not) but still nothing.
What am I missing?
The "Integration Console" in the Checkout Merchant Center gives you information about the callbacks (XML sent, XML received, HTTP errors, etc.). Hopefully you can figure out the problem from that data. Some related links below:
https://checkout.google.com/support/sell/bin/answer.py?hl=en&answer=72217
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#integration_issues_console
http://code.google.com/apis/checkout/articles/Troubleshoot_Integration_Console_Errors.html