Tailored Audience Stuck In Processing

[advolv]

A tailored audience uploaded via our app is stuck in processing. This issue is similar to what we posted here: Tailored Audiences stuck in processing for a particular account

We’ve made the change to our code so that the POST to accounts/:account_id/tailored_audience_changes suggested by @juanshishido is being fired. We don’t see any errors in our logs.

I don’t have the tailored audience ID but this is the account we’re referring to: https://ads.twitter.com/accounts/18ce54f8mdy/audience_manager

[juanshishido]

Thanks for reaching out, @advolv.

For reference, the tailored audience ID is 1md7e. It was created at 2016-12-23T22:13:31Z.

We are not seeing any record of a change—for example, operation=ADD—for this audience. This indicates, that the request to the POST accounts/:account_id/tailored_audience_changes endpoint was not successful.

Can you please confirm that you are:

• hashing the handles in the audience file
  • in addition to: using all lowercase characters, excluding the @ symbol, and removing leading and trailing spaces
• uploading the audience file using the TON API, with a ta_partner bucket name
• creating a placeholder tailored audience using the POST accounts/:account_id/tailored_audiences endpoint
• adding the records from the uploaded audience file to this tailored audience using the POST accounts/:account_id/tailored_audience_changes endpoint

[advolv]

Thanks for the quick reply, @juanshishido!!

We’re looking into this on our end now - hadn’t seen anything in the error log about that call failing but it’s good to get confirmation from your side. Will post an update asap.

[juanshishido]

Thanks, @advolv!

If this is failing silently, then we’ll have to update the response on our side. However, we’ll first need to reproduce this. Could you please share the request you’re making to the POST accounts/:account_id/tailored_audience_changes endpoint as well as the response you’re seeing? (If we don’t see anything out of the ordinary with this, we might need to see the requests and responses for the other steps in the process.)

[advolv]

Hey @juanshishido,

We just did a bunch of fixes and reimplemented the calls as you outlined above. We were previously doing the creation through the python twitter ads sdk and think we’ve isolated the issue.

When you upload smaller tailored audience files <1MB (as we were in tests), the TON API performs a non-chunked upload. But larger audiences >1MB are performed via the chunked method. What was happening (we think) is that the location returned by the TON API chunked upload had extra parameters attached (?resumable=true etc).

When this location was being passed to the POST tailored_audience_changes call, we were getting INVALID_PARAMETER, input_file_path errors as seen here:

Error uploading tailored audience when assigning placeholder to data - are there problems with V0 or have things changed? Anyone else experiencing this issue?

I am experiencing the same lag in processing for lists uploaded through the api. I have 3 lists uploaded to my advertiser account that have been processing for 35+ hrs now. Opened another topic as I need to get a response from Twitter re the lag:

This error, it would appear, was not being handled properly at our end. And our tests were being run with smaller audiences so we were missing it in a lot of cases. But we think we’ve fixed it. So far, what has seemed to work is stripping out these params and then sending the input_file_path. The 4 most recent attempts have uploaded and been processed successfully.

Thanks for the prompt help!

[juanshishido]

What was happening (we think) is that the location returned by the TON API chunked upload had extra parameters attached (?resumable=true etc).

This is correct. The response for a resumable (or chunked) upload initialization request includes the resumable and resumeId parameters. For additional details, see this.

The 4 most recent attempts have uploaded and been processed successfully.

That’s great! We’re seeing that three audiences (1mkle, 1mkoc, and 1mku8) have been successfully created in the past day and are ready to use. Please let us know if any other issues arise.

We appreciate you providing these details. They will help developers in the future who may come across these issues. Thanks!