I want to fetch keys from facebook using their graph Api. Currently i am being able to fetch keys that were pretty straightforward in graph api console like frequency , reach etc. Keys like purchase, Adds to cart are not available in the graph api console and their documentation isnt very explanatory. Most of these keys are not returning any value in facebook's ads manager as well.
It would be really helpful if anyone can explain:
When these metrics will be available ?
I have seen a tool qwaya and it copies all the columns that facebook provides. How are they doing it ?
What actions are to be performed on my ad so i can see any changes in
those values ( PURCHASE , ADDS TO CART etc )
Another side note : I was using facebook-ads-sdk but now they have changed its name to business-sdk
Related
I need to create a report on my custom Laravel web application to view customers campaigns and each cost and first visited customers count.
In that way user can make the decision campaign success or not.
is is possible to get these data with Google analytics "reports:batchGet" API or any other available API ?
I tried with below dimension
ga:acquisitionCampaign
But it's not clear what values I'm receiving with that dimension.
I'm using the Google places autocomplete widget and since Google applied the billing changes the widget is becoming very costly to maintain. I have added the basic parameters which are supposed to be free but when I view the billing I'm still getting charged for the SKU: Autocomplete without Places Details – Per Session. This is the code I'm using:
var searchBox = new google.maps.places.Autocomplete(input);
searchBox.setFields(['place_id', 'name', 'types']);
So my question is, is there a way to get the autocomplete dropdown without getting charged with the new google places API?
Please note that the setFields() method is only applicable when a user selects a place from the autocomplete suggestions. When a place is selected, a Places Details request is made which is the one that generates Data SKUs (Basic, Contact, and/or Atmosphere), depending on the fields that are specified in the request. If you specify Basic Data in your Places Details request, you will be billed for the Places Details request and not for any additional Data SKUs (like Atmosphere and Contact Data) when a user selects a place.
In your case you are only charged for all autocomplete requests and not with any Data SKU. To explain the charge that you got for SKU: Autocomplete without Places Details – Per Session, you are charged for this for the times when a user has not selected any place from the autocomplete suggestions within a few minutes of the beginning of the session. This happens when a user only types characters in the autocomplete input box but is not selecting any place from the search results.
If you have setup your billing account, you will be entitled to the recurring $200 monthly free credits.
Currently, since API requests are charged as per the pricing, if you want to stay in the free tier usage, you can cap your API usage by setting a daily limit to them. This is to avoid unexpected charges by limiting the number of API calls you can make per day.
Hope this clarifies it.
The pricing for implementing the autocomplete SearchBox is different than using the autocomplete widget. The searchbox uses the places text search functionality, which automatically bills for all three places data categories. The widget, however, allows you to mask data fields and automatically creates a session that begins when the user starts typing and ends when a selection is made. With the searchbox, you are getting billed per end user keystroke, which will rack up your charges incredibly fast. I highly recommend implementing the widget over the searchbox.
I am working on a SAAS project where users can create various projects. With each project, they can choose from 5 different plans. Each plan has its own costs per month. Hotjar is a kind of equal concept.
Now I want to arrange the subscription with Stripe. The problem with that was that a user can have a maximum x subscription, which of course was a shame. Then I decided to take 1 subscription that has several plans. But now I have a dilemma, to update the subscription you have to change the number via SubscriptionItem. Then you have to save yourself which plan has which SubscriptionItem_id for which user. That is quite a detour and can cause many problems.
Someone is a better way with Stripe or another payment software.
You don't necessarily need to store the subscritpion_item IDs, you can look it up via the subscription_item list API. All you need to do is store the subscription_id for your customers, and based on that ID you can retrieve the list of subscription_items:
\Stripe\Stripe::setApiKey("sk_test_9GavlLpfiKewqeCBXvRvmVgd");
\Stripe\SubscriptionItem::all(["subscription" => "sub_EQlPGjVj4o5luH"]);
Then you can handle the data part of the returned JSON object and update / delete / etc these subscription items.
If you only have the customer_id handy, then you can use the subscription list API (with status as well on the GET params) to retrieve the list of active subscriptions.
I understand that the Square POS API does not currently support the ability for an external app to pass itemized line items when calling Square to process the payment. Is there a way for the external app to associate the itemized details with the completed sale transaction in Square via an API after the payment is completed and square returns control to the external app?
Are there specific plans to provide support for itemized transactions within the POS API?
There's no way to formally do this currently, and there's no current timeline or guarantee that it will be released for the POS API.
It's possible to link it via the Orders API in a workaround. Basically, prior to initializing the transaction, you would call CreateOrder with the items in the order. The response would give you an Order object, which you can retrieve the order_id from. Then, you can pass in the order_id into the notes field when creating the POS API request. This would allow you to at least look up the itemization later on (by utilizing BatchRetrieveOrders) for each of the POS API transactions.
Furthermore, if you are going further and utilizing your own database, then you wouldn't even need to pass in the order_id to the note field, as you could just link the order_id and transaction_id in your own database for easy lookup later.
References:
https://docs.connect.squareup.com/more-apis/orders/overview
https://docs.connect.squareup.com/api/connect/v2#navsection-orders
When we wrote or initial integration for Square v1 API, there wasn't an option to filter ListOrders by Date
Our questions for v2 api:
In v2, looks like all transactions are housed under the same endpoint.
Okay, we call GET /transactions
How do we tell what is an order vs. payment vs. refund in the response?
not all payments are generated off an order. For example, I can do one-off Square transactions on my phone for walk-up customers, which would not have an order associated with it)
Can we filter for orders only?
Does the Transaction endpoint supports date filtering now?
Thank you for your time
Take a look at the documentation for the v2 Transaction object. Refunds and orders are subsets of that object.
Also look at the documentation for the List Transactions where you can see that you can currently filter based on times only right now.
If it isn't listed in the documentation, then it probably isn't supported.