Home App Docs Blog Github

Content Targetting Options not working

Please fill out as many of the following questions as possible so we can help you promptly! If you don’t know how to answer or it does not apply, feel free to remove it or leave it blank.

Builder content link
e.g. builder.io/content/4cab34394e684fe7b93d6ef5493a8a51

Builder public api key

What are you trying to accomplish
I am trying to use builder’s targetting capabilities but the API does not appear to be respecting the configured targets. I have a targetting attribute newuser which is set as boolean.

I have two pieces of content, both configured with the same urlPath “/”
I then have one peice of content that is configured with newuser = true

However the API (and the SDK) only return whichever piece of content is first. They appear to be ignoring the queried targetting attribute.

See this API query to reproduce: https://cdn.builder.io/api/v2/content/page?apiKey=d8a6546473bd4f2794811a138f34b99a&userAttributes.urlPath=/&userAttributes.newuser=true&limit=1&fields=id,name,data.newuser

Code stack you are integrating Builder with

Builder will send the content match with the highest priority, double check the content order in the list view and re-arrange it to alter its priority. For more details, please refer to this section of the targeting documentation,

Thanks Aziz. That makes sense, but builder is sending me the higher priority content that does not match the targeting parameters. I am passing in newuser=True and receiving a page that does not have that setting.

Sent from Front

Targeting in builder works by sending the highest priority content with a match on any of the targeting attributes you send, so when sending those two user attributes

urlPath: '/',
newUser: true,

Content API will send the the content with the highest priority that has newIUser: true or urlPath: '/', keeping the most permissive content (less targeting attributes) lower in the list will guarantee you’re serving the most personalized content first.

Thanks Aziz, so in that situation am I correct in assuming that I will never receive the second page? Since every request is going to have the urlPath: ‘/’ I am always going to receive whichever page is higher in priority regardless of secondary targeting. Is that correct?

Is there a way to use an AND based query instead of an OR? I think this would be more useful given that the idea here is to create multiple versions of the same page (with the same urlPath) and then select the one that matches the other targeting parameters.


Yes, as the query is written above, that is correct.

Yes! There is, using the Content API and a custom field on the content (for example newUser of type Boolean) and adding custom query to the request query.data.newUser=true&userAttributes.urlPath=/ you should be able to achieve what you are looking for.

Try it out and let us know if you have any further questions

Hey Tim,

That query doesn’t seem to be working. I am not getting anything back at all.

Here is the URL I am trying:

I have tried pretty much every version of capitalization for the “newuser” attribute. Do you know what is wrong here?

Secondly, if we get the query correct how do I execute that with with SDK? I have been trying to pass the attributes in using setUserAttributes, but there doesn’t appear to be any documentation for any other sort of querying within the SDK.


Sent from Front

@sellandb I can look into why that isnt working. In the meantime, there are a few things you can do to achieve your desired result.

As @aziz mentioned above, content is prioritized by list order in Builder.io: Drag and drop page builder and CMS. If you move Homepage - New User above Homepage in the list, then your original query should give you desired result:

Similarly, if for some reason you don’t want to change the stack order, you can explicitly set the original Homepage to target for newuser=false, I think that should limit which page you see. However I wouldn’t recommend it since it is always best to have a fall back page without any limiting parameters.

As for setUserAttributes, you should be able to just include i

  urlPath: '/',
  newuser: true

inside whichever component you are integrating to Builder. You can see an example in the SDK documentation here

Not sure your exact tech stack and setup, but if you are setting the newuser attribute based on say a cookie, you may need to run whatever logic for setting the user attributes within the browser, and you can see examples of how to do that here: