How can i collect Ads impression and revenue data with Facebook Analytics?
For instance, i have google ads in the application, i would like to collect these data as if collected IAP data. In firebase, when you integrate your admob account, data of ads are collected automatically.
Is there a way to do it on Facebook Analytics either automatically or manually?
Thanks.
There is no automatic way currently for that, we do (our SDK both for iOS and Android) supports automatic in-app purchase instrumentation. But I guess your case it is more tricky, as this is not really an IAP. Allow me to propose two options:
1) Client side - you integrate FB SDK, hook to Ads impression callback (viewed and/or clicked) and fire custom event, like logEvent('ad', ad_id, ...) or standard event such as logPurchase() event.
Relevant link:
https://developers.facebook.com/docs/app-events
2) Server side - export from GA / Firebase relevant events, and send them to our endpoint .../app_id/activities
Relevant link:
https://developers.facebook.com/docs/marketing-api/app-event-api
Sincerely,
Eli from Facebook Analytics
Related
Just wondering if someone can clear this up for me as its kind of a grey area and not sure what to do.
I have a website that is split into frontend and api and has a subscription service provided by stripe on the api. I am now making apps in ionic for both apple and google stores but Im unsure of how the payments will work on the platforms, ideally i would like to just stick to using stripe but Ive been reading about both stores and this is where I need guidance.
From what I have read it seems to be that I have to use google play billing and apples alternative. Do I have to use these for the apps going into their respective stores or can I continue to use stripe within the apps? As i see it its a multi platform saas. So why cant I just send the card info to my api for charging?(I know theres alot of security involved and its not as trivial as I make it out to be)
Ive been reading conflicting statements from multiple sites and Im just not sure which is correct and the docs on google play billing make no reference to this. Its a multiplatform service so can I just send on the card details to my api
But what I have found is that apple have this
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
Which to me states that I have to use Apple Pay and make no reference to my other payment methods for fear of being refused from the store.
I can't comment for Apple. For Google Play the best place to answer this sort of question is the Developer policy center. In the Monetization and Ads section it says
Developers offering products within another category of app downloaded on Google Play must use Google Play In-app Billing as the method of payment, except for the following cases:
Payment is solely for physical products
Payment is for digital content that may be consumed outside of the app itself (e.g. songs that can be played on other music players).
You should read all of the linked page and decide what category the stuff you are selling falls into.
We do validate the google play in app purchase receipt on our backend server.
For testing we do fake the receipts and test with them our system.
Is there a possibility to do a test purchase from the backend server to google's test server, to generate a receipt?
Or is there a possibility to get an fake receipt directly from google play?
For Android there are static responses for testing, maybe for backend server too.
It will be a better test then to fake the receipt by my own.
All purchases, including test purchases, must be done using an Android application (via a real device or an emulator). It happens because the purchase is executed by the Google Play Store app, and authenticated by the user.
About the server-side API, according to the Google Play Developer API, you can use the Subscriptions and In-App Purchases API to:
[...] manage your app's catalog of in-app products and subscriptions. In
addition, with the Subscriptions and In-App Purchases API you can
quickly retrieve the details of any purchase using a standard GET
request.
So, after your purchase is completed (starting on the device), you can manage it's status, get details from the API and etc.
Our app has already implemented in-app purchase.
But, we previously don't keep track of it, and only relies on the google's service whether a user's level is premium or regular.
Now, we want to track it in our server as well.
Is it possible to get the users data who've bought our subscriptions? (especially his/her email)
Based from the following documentations, there is no currently existing method to get a list of your app's subscriber's.
Google Play Developer - API Reference
In-app Subscriptions
Currently existing features with Google Play Developer API is that, it offers an HTTP-based API that lets you perform such tasks as:
Remotely query the validity of a specific subscription at any time
Cancel a subscription
Defer a subscription's next billing date
Refund a subscription payment without canceling the subscription
Refund and revoke a subscription
The API is designed to be used from your backend servers as a way of securely managing subscriptions, as well as extending and integrating subscriptions with other services.
For complete information, you may go through Google Play Developer API.
I am about to build a simple webapp that has several tasks, each of which has got a due date.
I would like this webapp to automatically sync with Google Calendar, Outlook and Apple Calendar - 2-way integration would be a plus.
The webapp is built on a LAMP server.
What's the cleverest way I can go about this from a point of view of limiting the workload as much as possible?
And also, is that even possible? I wasn't able to find an API for Outlook or Apple Calendar.
Is CalDev the answer? Is there any product/software that will do that automatically, so that I need only to sync with it and it will do the rest?
Thanks.
You could do the following:
Synchronize your proprietary calendar with Google Calendar (make this your "master calendar") using the GCal API; if your application can produce a valid ICS file then you can import it directly to Google Calendar. As this feature is discontinued by Google you can use some online WebDAV based import/export service (I use for this Synqya)
Use the WebDAV access to the Google Calendar to synchronize Outlook and Apple Calendar with it using their calendar subscription features (this would be one way sync). If you need secured access to GCal and 2-way sync, it will involve further steps.
A recent Ars Technica article rekindled my interest in WebOS so I was looking at the Services API (because I'm interested in building a replacement calendar app). I discovered the following text at the top of the calendar services API documentation:
Note: To prevent unauthorized use of
private user data, this API provides
access only to records created by your
application; that is, you cannot
access records owned by another
application.
What is the point of even having an API if you can't access data created by other applications? At that point there would be no reason for me to use their API rather than building the data storage myself. Am I missing something? Can any WebOS developers weigh in on this?
P.S. If they named their os "WebOS" you would think they'd know something about sane URLs. Check out that ridiculous calendar api doc url!!
The reason for the limited access is because of security, but not just that. Some services have agreements that limit how their data can be used. For example, having an API that would let a random webOS app access your Facebook calendar data would be working around the FaceBook terms of service that control how that data can be used. The same applies to LinkedIn, Google Calendar, and any other service from which the system is pulling information.
If you just need to post an occasional event, there's a better API to use that lets you cross-launch the calendar app with data that the user can accept into their own calendar. That way, you don't create your own bucket, but the user has to manually accept the event.
The reason to use the calendar APIs is to expose your own data to the user of the device. FlightView, for example, uses it to publish a calendar to the user of upcoming flights that he or she is interested in, and if those get rescheduled, it can automatically change them. The Fandango app uses this to push movie times for theaters the user likes into their calendar view. There's lots of possibilities.