When using the action breakdown to view the offsite conversions:
act_[ACT_NUM]/reportstats?date_preset=last_3_days&increment=1&data_columns=['campaign_group_id','campaign_group_name','actions']&actions_group_by=['action_type','action_target_id']&limit=1000
amongst the response will usually be something like:
...
{
"action_type": "offsite_conversion.lead",
"action_target_id": "[object_id_1]",
"value": 3
},
{
"action_type": "offsite_conversion.other",
"action_target_id": "[object_id_1]",
"value": 1
},
{
"action_type": "offsite_conversion.other",
"action_target_id": "[object_id_2]",
"value": 7
}
...
We've been using the action_target_id to link to conversion pixels by their id and this still mostly works. However the facebook report on conversion pixels seems to have added the action values for stats with the same tag as the conversion pixel but with different action_target_ids. For example the above referenced object_id_1 for the lead stat appears to link to a creative but its value has been added to the total conversions for one of the lead tagged conversion pixels attached to the account. Not sure if it's relevant but this seems to only be happening to multi product ads on the accounts I've looked at.
Anyone have an idea why this might be the case and whether or not it is possible to consistently link the response from the action breakdown in report stats to conversion pixels?
Related
I'm searching to display in a DD Dashboard the date of the last value of a metric. I can use a simple QueryValue field for that, however I don't know how I can get the date of this metric instead of its value.
Example :
mymetric = [21,5,42]
let's say that the relevant dates for those metrics are
['1/1/2022', '1/2/2022', '27/2/2022']
I'd like to display 27/2/2022.
For now, I'm displaying only the value with this query
"queries": [
{
"query": "max:mycounter{$env}",
"data_source": "metrics",
"name": "query1",
"aggregator": "last"
}
]
Is it possible with Datadog ?
In fact I've found a workaround, but that seems a little bit unoptimized. I push also from my code mycounter.date_day mycounter.date_month and mycounter.date_year. And then I can display day month year in 3 different QueryValue.
Regards,
Blured.
This is not a use case Datadog metrics are designed for. Any solution you find is going to be pretty hacky.
This seems like maybe instead of a custom metric, you'd want to be sending a log or event, with date/time attributes that you can display. Even that doesn't really sound close to what you're looking for though.
If you really wanted to get this working in a clean way, I suppose you could try developing your own custom Datadog widget as an app: https://www.datadoghq.com/blog/datadog-apps/ (reference docs)
But whatever your goal is might just have to be redesigned to make more sense for what Datadog is built for.
I was wondering if an object type that has an id property has to have the same content given the same id. At the moment the same id can have different content.
The following query:
const query = gql`
query products(
$priceSelector: PriceSelectorInput!
) {
productProjectionSearch(
priceSelector: $priceSelector
) {
total
results {
masterVariant {
# If you do the following it will work
# anythingButId: id
id
scopedPrice {
country
}
}
}
}
}
`;
If the PriceSelectorInput is {currency: "USD", country: "US"} then the result is:
{
"productProjectionSearch": {
"total": 2702,
"results": [
{
"name": "Sweater Pinko white",
"masterVariant": {
"id": 1,
"scopedPrice": {
"country": "US",
"__typename": "ScopedPrice"
},
"__typename": "ProductSearchVariant"
},
"__typename": "ProductProjection"
}
],
"__typename": "ProductProjectionSearchResult"
}
}
If the PriceSelectorInput is {currency: "EUR", country: "DE"} then the result is:
{
"productProjectionSearch": {
"total": 2702,
"results": [
{
"name": "Sweater Pinko white",
"masterVariant": {
"id": 1,
"scopedPrice": {
"country": "DE",
"__typename": "ScopedPrice"
},
"__typename": "ProductSearchVariant"
},
"__typename": "ProductProjection"
}
],
"__typename": "ProductProjectionSearchResult"
}
}
My question is that masterVariant of type ProductSearchVariant has id of 1 in both cases but different values for scopedPrice. This breaks apollo cache defaultDataIdFromObject function as demonstrated in this repo. My question is; is this a bug in apollo or would this be a violation of a graphql standard in the type definition of ProductSearchVariant?
TLDR
No it does not break the spec. The spec forces absolutely nothing in regards caching.
Literature for people that may be interested
From the end of the overview section
Because of these principles [... one] can quickly become productive without reading extensive documentation and with little or no formal training. To enable that experience, there must be those that build those servers and tools.
The following formal specification serves as a reference for those builders. It describes the language and its grammar, the type system and the introspection system used to query it, and the execution and validation engines with the algorithms to power them. The goal of this specification is to provide a foundation and framework for an ecosystem of GraphQL tools, client libraries, and server implementations -- spanning both organizations and platforms -- that has yet to be built. We look forward to working with the community in order to do that.
As we just saw the spec says nothing about caching or implementation details, that's left out to the community. The rest of the paper proceeds to give details on how the type-system, the language, requests and responses should be handled.
Also note that the document does not mention which underlying protocol is being used (although commonly it's HTTP). You could effectively run GraphQL communication over a USB device or over infra-red light.
We hosted an interesting talk at our tech conferences which you might find interesting. Here's a link:
GraphQL Anywhere - Our Journey With GraphQL Mesh & Schema Stitching • Uri Goldshtein • GOTO 2021
If we "Ctrl+F" ourselves to look for things as "Cache" or "ID" we can find the following section which I think would help get to a conclusion here:
ID
The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache. The ID type is serialized in the same way as a String; however, it is not intended to be human‐readable. While it is often numeric, it should always serialize as a String.
Result Coercion
GraphQL is agnostic to ID format, and serializes to string to ensure consistency across many formats ID could represent, from small auto‐increment numbers, to large 128‐bit random numbers, to base64 encoded values, or string values of a format like GUID.
GraphQL servers should coerce as appropriate given the ID formats they expect. When coercion is not possible they must raise a field error.
Input Coercion
When expected as an input type, any string (such as "4") or integer (such as 4) input value should be coerced to ID as appropriate for the ID formats a given GraphQL server expects. Any other input value, including float input values (such as 4.0), must raise a query error indicating an incorrect type.
It mentions that such field it is commonly used as a cache key (and that's the default cache key for the Apollo collection of GraphQL implementations) but it doesn't tell us anything about "consistency of the returned data".
Here's the link for the full specification document for GraphQL
Warning! Opinionated - My take on ID's
Of course all I am about to say has nothing to do with the GraphQL specification
Sometimes an ID is not enough of a piece of information to decide whether to cache something. Let's think about user searches:
If I have a FavouriteSearch entity that has an ID on my database and a field called textSearch. I'd commonly like to expose a property results: [Result!]! on my GraphQL specification referencing all the results that this specific text search yielded.
These results are very likely to be different from the moment I make the search or five minutes later when I revisit my favourite search. (Thinking about a text-search on a platform such as TikTok where users may massively upload content).
So based on this definition of the entity FavouriteSearch it makes sense that the caching behavior is rather unexpected.
If we think of the problem from a different angle we might want a SearchResults entity which could have an ID and a timestamp and have a join-table where we reference all those posts that were related to the initial text-search and in that case it would make sense to return a consistent content for the property results on our GraphQL schema.
Thing is that it depends on how we define our entities and it's ultimately not related to the GraphQL spec
A solution for your problem
You can specify how Apollo generates the key for later use as key on the cache as #Matt already pointed in the comments. You may want to tap into that and override that behavior for those entitites that have a __type equal to your masterVariant property type and return NO_KEY for all of them (or similar) in order to avoid caching from your ApolloClient on those specific fields.
I hope this was helpful!
I'm using Gatsby and graphql with headless WordPress for a website.
I want to use a gatsby-image plugin to get srcSet and blurring effect for images that are coming from WordPress, but it throws an error in graphiQL playground. I want to explain below the whole process step by step for the best understanding.
The gatsby-image plugin has two types of responsive image fixed and fluid:
To decide between the two, ask yourself: “do I know the exact size this image will be?” If yes, it’s the first type. If no and its width and/or height need to vary depending on the size of the screen, then it’s the second type.
so, I need the second one - fluid.
It also has two image components Static and Dynamic.
If you are using an image that will be the same each time the component is used, such as a logo or front page hero image, you can use the StaticImage component.
If you need to have dynamic images (such as if they are coming from a CMS), you can load them via GraphQL and display them using the GatsbyImage component.
I'm using WordPress (which is CMS). So, I need the second one - Dynamic
Before writing a query, I must see how to make the right query for the files coming from the WordPress scheme.
For this reason, I found that Gatsby has a gatsby-source-wordpress plugin to pull images from WordPress.
I've installed and configured all the required packages such as gatsby-plugin-image,gatsby-plugin-sharp, gatsby-transformer-sharp, etc. I did Everything as exactly as the official docs say.
At that time everything was prepared to make a query, so I try the first example that they have in docs - pulling images from wordpress and IT WORKED.
So it's time to FINALLY GET WHAT I WANTED and try the second example (fluid), but IT FAILED with an error message Cannot return null for non-nullable field ImageSharpFluid.srcSet.
It also FAILS when I try to get gatsbyImageData
How could I fix this problem?
Thanks in advance.
The documentation you mention for gatsby-source-wordpress is outdated. Checkout this one: https://www.gatsbyjs.com/plugins/gatsby-source-wordpress/
Your query looks like the old one. I'm not sure what plugin versions you are running, but if you are running the latest ones your query should look something like this:
query MyQuery {
allWpPost {
nodes {
featuredImage {
node {
localFile {
childrenImageSharp {
gatsbyImageData(width: 200, placeholder: BLURRED, formats: [AVIF, WEBP, JPG])
}
}
}
}
}
}
}
Also the gatsby-image plugin is deprecated in favor of gatsby-plugin-image.
If you want an example of how the setup is put together you can search the starters for CMS:WordPress and v3 to find one to start with. Gatsby Starters
Hope this gets you started :)
If You have used caching in your plugin options like the code below, Try deleting the .cache folder in your workspace and restart the server.
{
resolve: `gatsby-source-wordpress`,
options: {
production: {
hardCacheMediaFiles: true,
},
},
},
Probably It would take time fetching the images and then your page should load without any errors.
I'm currently working on a project in which we perform "Nearby" queries for places using keywords, and then we make follow-up "Detail" requests to obtain more information about specific places of interest.
With Google's new pricing model in the works, the documentation warns about the cost of the Nearby search, but the warning seems to imply that the follow-up detail request will no longer be necessary because our original search should give us everything we need:
By default, when a user selects a place, Nearby Search returns all of
the available data fields for the selected place, and you will be
billed accordingly. There is no way to constrain Nearby Search
requests to only return specific fields. To keep from requesting (and
paying for) data that you don't need, use a Find Place request
instead.
However, I'm not seeing this. When I run a sample request, the results from my Nearby request contains only minimal data related to the places Google finds. To get details, I still have to do a follow-up detail request.
Does anyone know if there's something I may be overlooking? I'm including my request URL (sans API key).
https://maps.googleapis.com/maps/api/place/nearbysearch/json?key=xxxxxxxxxx&location=30.7329,-88.081987&radius=5000&keyword=insurance
And this is an example of one of the results I received:
{
"geometry": {
"location": {
"lat": 30.69254,
"lng": -88.0443999
},
"viewport": {
"northeast": {
"lat": 30.69387672989272,
"lng": -88.04309162010728
},
"southwest": {
"lat": 30.69117707010728,
"lng": -88.04579127989273
}
}
},
"icon": "https://maps.gstatic.com/mapfiles/place_api/icons/generic_business-71.png",
"id": "53744cdc03f8a9726593a767424b14f7f8f86049",
"name": "Ann M Hartwell - Aflac Insurance Agent",
"place_id": "ChIJj29KxNZPmogRJovoXjMDpQI",
"plus_code": {
"compound_code": "MXV4+26 Mobile, Alabama",
"global_code": "862HMXV4+26"
},
"reference": "CmRbAAAAcHM1P7KgNiZgVOm1pWojLto9Bqx96h2BkA-IyfN5oAz1-OICsRXiZOgwmwHb-eX7z679eFjpzPzey0brgect1UMsAiyawKpb5NLlgr_Pk8wBJpagRcKQF1VSvEm7Nq6CEhCfR0pM5wiiwpqAE1eE6eCRGhQPJfQWcWllOVQ5e1yVpZYbCsD01w",
"scope": "GOOGLE",
"types": [
"insurance_agency",
"point_of_interest",
"establishment"
],
"vicinity": "70 N Joachim St, Mobile"
}
I thought about deleting this question, but I guess I'll leave it up in case anyone else is confused like I was.
It turns out the extra detail fields I was looking for in the Nearby Search results were there...sort of.
Google's new pricing model categorizes place data fields into three tiers: Basic, Contact, and Atmosphere (Basic data is free, but the other two add to the cost).
As part of these changes, Place API calls have been expanded to allow users to specify the data fields they want so that they don't have to pay for that extra data if they don't need it.
The Nearby Search query, as per the note in the question, includes all the data fields available, and doesn't support a parameter for controlling the data -- it's always going return data that falls into the [Basic + Contact + Atmosphere] bucket.
So far, that's all well and good.
Where things became confusing to me, though, is the specifics of what is included in the different data tiers. I skimmed through these notes several times before I noticed the contents were different.
This is how the fields break down with the Places details request:
Basic
The Basic category includes the following fields: address_component,
adr_address, alt_id, formatted_address, geometry, icon, id, name,
permanently_closed, photo, place_id, plus_code, scope, type, url,
utc_offset, vicinity
Contact
The Contact category includes the following fields:
formatted_phone_number, international_phone_number, opening_hours,
website
Atmosphere
The Atmosphere category includes the following fields: price_level,
rating, review
And this is how it looks for the Places search request:
Basic
The Basic category includes the following fields: formatted_address,
geometry, icon, id, name, permanently_closed, photos, place_id,
plus_code, scope, types
Contact
The Contact category includes the following field: opening_hours
(Place Search returns only open_now; use a Place Details request to
get the full opening_hours results). Atmosphere
The Atmosphere category includes the following fields: price_level,
rating
I haven't found documentation for it, specifically, but the results from a Nearby Search request seems close (but not identical) to the Place search (including Contact and Atmosphere).
I had originally thought the fact that Nearby Search results now include Contact and Atmosphere data (when available), that meant it would contain all the fields itemized as Contact and Atmosphere data in the Place details documentation, but that's not the case.
Since today I have problem with one of 2 similar calls to Google Calendar API v3:
calendar.events.list
Both calls are requesting list of assignemnts and use privateExtendedProperty to filter them, but key=Value pairs are different.
When I have privateExtendedProperty set to myStatus=READY it returns events I need,
but when I set privateExtendedProperty to myId=agxzfm1haWxmb29nYWVyNQsSDE9yZ2FuaXphdGlvbiIVYWN0aXZlZ2FtaW5nbWVkaWEuY29tDAsSBENhc2UYkcHA3wgM
it returns no events, though I'm sure there are several events with this myId...
It appears that the calendar API list is returning an empty list when querying by a privateExtendedProperty with 90 characters long.
Everything worked fine for years, but it suddenly broke for some of my users this morning...
This is my request:
GET googleapis.com/calendar/v3/calendars/****/events?privateExtendedProperty=myId%3Dagxzfm1haWxmb29nYWVyNQsSDE9yZ2FuaXphdGlvbiIVYWN0aXZlZ2FtaW5nbWVkaWEuY29tDAsSBENhc2UYwauk6QgM&key={YOUR_API_KEY}
This is the result I see in API explorer:
{
"kind": "calendar#events",
"etag": "\"*****\"",
"summary": "*****",
"description": "*****",
"updated": "2018-02-20T03:18:35.098Z",
"timeZone": "Asia/Tokyo",
"accessRole": "owner",
"defaultReminders": [
],
"nextSyncToken": "CJDv1KDEs9kCEJDv1KDEs9kCGAU=",
"items": [
]
}
Update 1:
My privateExtendedProperty looks like this:
{
"myStatus": "READY",
"myId": "agxzfm1haWxmb29nYWVyNQsSDE9yZ2FuaXphdGlvbiIVYWN0aXZlZ2FtaW5nbWVkaWEuY29tDAsSBENhc2UYkcHA3wgM",
"another": "Another value",
"another2": "Another value2"
}
When I query events with "myStatus=READY" - event is returned, but when I do the same with "myId=agxzfm1..." - it returns emtpy list.
Update 2:
For those who have the same issue. As per suggestion, I created a new calendar and then duplicated some test data and tried long value in privateExtendedProperty query and it returned event as expected. It means, if this is a bug - not all calendars are affected and moving things to a new calendar might be a way to go.
The document for Extended Properties says the limitations as follows.
The maximum size of a property's key is 44 characters, and properties with longer keys will be silently dropped.
The maximum size of a property's value is 1024 characters, and properties with longer values will be silently truncated.
An event can have up to 300 shared properties totaling up to 32kB in size (keys size + value size).
An event can have up to 300 private properties, totaling up to 32kB in size (keys size + value size), across all "copies" of the event.
From this, it seems that your case is out of the above limitations. In my environment, also I tried your situation. As the result, it was found that myId=agxzfm1haWxmb29nYWVyNQsSDE9yZ2FuaXphdGlvbiIVYWN0aXZlZ2FtaW5nbWVkaWEuY29tDAsSBENhc2UYkcHA3wgM can be used.
So can you confirm the following points again?
It seems that your result retrieved by API explorer doesn't included extendedProperties in the property of items. When you set extendedProperties, it can be seen. If you use fields, it might be not able to be seen.
Can you set extendedProperties with myId=agxzfm1haWxmb29nYWVyNQsSDE9yZ2FuaXphdGlvbiIVYWN0aXZlZ2FtaW5nbWVkaWEuY29tDAsSBENhc2UYkcHA3wgM again?
You can set it using calendar.events.patch.
When you retrieve events with myId=agxzfm1haWxmb29nYWVyNQsSDE9yZ2FuaXphdGlvbiIVYWN0aXZlZ2FtaW5nbWVkaWEuY29tDAsSBENhc2UYkcHA3wgM using calendar.events.list, if you use the URL encoded value of myId%3dagxzfm1haWxmb29nYWVyNQsSDE9yZ2FuaXphdGlvbiIVYWN0aXZlZ2FtaW5nbWVkaWEuY29tDAsSBENhc2UYkcHA3wgM, please try to use the value without URL encode.
If this was not useful for you and I misunderstand your question, I'm sorry.
Edit :
If you retrieve the event using calendar.events.get, can the extendedProperties you set be seen? If you cannot see it, please insert extendedProperties again.
The endpoint is GET https://www.googleapis.com/calendar/v3/calendars/### calendar Id ###/events/### event Id ###?fields=extendedProperties%2Fprivate
In my environment, the same endpoint of yours works fine. So as a test, can you try to create new calendar and run that query? Because I worried whether the recent update of calendar affects this situation.