Tailored Audience stuck in "Processing" state

[JBabichJapan]

Hi,

I checked and there are no known issues right now with processing pipeline.

Could you please let me know if you are setting up “LIST” or “WEB” based audiences? (The latter being cookie-sync based audiences) For web audiences one reason they may be stuck at too small is that the ID sync is not happening properly. If it’s LIST audiences, it could be that 99% of the users are not active or something like that but a good way to check would be to upload subset via the traditional ton upload or list upload available within ads.twitter.com and if those definitely are not “TOO_SMALL” then it could be a problem with how you are posting data to tailored_audience_memberships.

Thanks,

John

[Andrey]

Hi John,

We don’t set membership_type parameter, as it’s marked as optional in the documentation. Should we try to add it?

We send the following kind of JSON in batch requests:

[
{
“operation_type”: “Update”,
“params”: {
“advertiser_account_id”: “18h7jk9hx”,
“user_identifier”: “123456789”,
“user_identifier_type”: “TWITTER_ID”,
“audience_names”: “Test”,
“effective_at”: “2017-01-26T15:22:13Z”,
“expires_at”: “2017-01-28T15:22:13Z”
}
},
{
“operation_type”: “Update”,
“params”: {
“advertiser_account_id”: “18h7jk9hx”,
“user_identifier”: “1234567890000”,
“user_identifier_type”: “TWITTER_ID”,
“audience_names”: “Test”,
“effective_at”: “2017-01-26T15:22:13Z”,
“expires_at”: “2017-01-28T15:22:13Z”
}
}
]

Do you spot any problems with it? We set expiration date to 48h hours, could this be too short?

[JBabichJapan]

I would go ahead and set it because I’m not sure without digging whether that is a documentation mistake or not, and it seems fine to be explicit with what you are trying to do.

I would definitely make the expires_at date longer if you want the audience to be usable for a long period of time, the user will be removed from the audience after the date you set there. I believe some partners are setting that even to something like 2099.

Thanks,

John

[Andrey]

Hi John,

I added membership_type and extended expires_at to 30 days. However this didn’t help, the audience is still in processing&too_small state since 2 days:

{
“targetable”: false,
“name”: “Advertising2”,
“targetable_types”: [
“CRM”,
“EXCLUDED_CRM”
],
“audience_type”: “CRM”,
“permission_level”: “READ_WRITE”,
“is_owner”: true,
“id”: “1xv6u”,
“reasons_not_targetable”: [
“PROCESSING”,
“TOO_SMALL”
],
“list_type”: “TWITTER_ID”,
“created_at”: “2017-02-01T07:16:02Z”,
“updated_at”: “2017-02-01T07:16:02Z”,
“partner_source”: “OTHER”,
“deleted”: false,
“audience_size”: null
}

It should contain quite large set of users >800k. Even if some % of them are inactive, there must be enough to validate the audience with required minimum of 5K.

Previously we used ton upload endpoint, but it didn’t seem to work well either. Only one audience were transitioned to READY with ~200k users. Others were stuck in Processing state. API didn’t return any errors.

How can we trace the problem?

Thanks,
Andrey

[JBabichJapan]

For the last audience you posted (1xv6u) the internal status is that we didn’t find a single user from the uploaded data, so I think it’s not hashed correctly or some basic thing is wrong. To protect user privacy, we require the data for types described in https://dev.twitter.com/ads/audiences/file-data be hashed

[Andrey]

I tried to submit a list of IDs through Twitter’s Audience Manager Tool and it worked. Also made a hashed list, to make sure hashing works, and it got validated. However hashing IDs for batch queries doesn’t seem to help. Here are their IDs 1zv19 and 1zmj6.

[Andrey]

@JBabichJapan, could you check this? We don’t have any progress with it.

[imit8me]

Hey @Andrey

Apologies for the delay in response. We’re still investigating the issue, and haven’t been able to determine a root cause yet. We’ll definitely reach out once we’ve got some more context around what’s going on.

Appreciate your patience.

Thanks!

[imit8me]

Hey @Andrey

Can you confirm that you used the POST tailored_audience_change endpoint after uploading your audiences? We don’t see a request associated with the two Tailored Audience id’s mentioned in your request, i.e., 1zv19 and 1zmj6

Thanks!

[Andrey]

Hi @imit8me!

No, we are using realtime API at 1/tailored_audience_memberships from https://dev.twitter.com/ads/audiences/ta-realtime-integration-guide

[JBabichJapan]

Hey Andrey,

I am guessing you are not hashing the values passed into user_identifier parameter. These need to be hashed the same way as you hash when uploading to ton_upload endpoint. Can you confirm you are doing hashing?

Thanks
,
John

[Andrey]

Hi John,

Yes, we added ID hashing to JSON queries, as you’ve suggested. But unfortunately this didn’t fix the problem.

Is there anything else we could try?

[JBabichJapan]

Did you try making sure to set the expires_at to a longer window?

Can you give the name of the audience uploaded via tailored_audience_memberships which you’re the most sure should have plenty of users, but not showing in the UI?

[JBabichJapan]

Also, it would be best if you can try to upload an audience from scratch one more time since so much time has passed since the original posting (just to make sure there was not a temporary issue on our side that has since been fixed).

[Andrey]

I uploaded a new audience id=20luk, it’s showing now as Processing. The IDs are hashed and expiration dates are extended to 30 days.

[JBabichJapan]

Hi Andrey,

Is this issue solved with latest uploads?

Thanks,

John

[Andrey]

Hi!

Yes, I got it finally working. There were some issues with twitter4j library in the part that was added to support this new endpoint.

[imit8me]

Hey @Andrey

Thats fantastic news! Can you let us know specifically what the issue was with the library? This way we can perhaps update the source with the fix as well. Also - please consider marking this thread as resolved, as well.

Thanks!

[chet]

Hi @imit8me @JBabichJapan I’m getting the same thing on the PROCESSING side of things with no meaningful debugging information. I’m not using any special library like the requester above. I’m hitting the new APIv2 endpoint (https://ads-api.twitter.com/2/tailored_audience_memberships)

This is a test send to show what the POST data looks like–can the hash of email be lowercase?
My request looks like:

[{u'operation_type': u'Update', 
u'params': {u'membership_type': u'LIST_MEMBERSHIP', 
u'user_identifier_type': u'EMAIL', 
u'audience_names': 'chet-test', 
u'expires_at': '2018-08-08T23:49:42Z', 
u'user_identifier': 'a72a7fbb8e21ed3b186677abcafe767b23ffe2c391da164290111e6d8292fc62', 
u'advertiser_account_id': u'18ce53ur9es'}}]

Headers:
{'content-type': 'application/json', auth...}

I’m actually using this on behalf of an organization with ID “99ofz”. An example audience that is caught in PROCESSING | TOO SMALL is audience id “28asn”.

Thanks for your help.

[JBabichJapan]

Sorry for missing your reply here - it might be better to post a new thread to make sure it doesn’t get overlooked.

E-mails should be lowercase and remove trailing and leading spaces, then SHA256 without a salt. You can find example for hashing here: https://github.com/twitterdev/ton-upload/blob/master/ton_upload or https://github.com/twitterdev/ads-platform-tools/blob/master/python/hash_tailored_audience_file.py

The audiences require a minimum size of active users to be able to be used in targeting campaigns. I would recommend using a larger e-mail data set to test with or handles. You can also try the upload with ton_upload above and compare result, you should be able to get to the same result with the memberships API.

Please go ahead and post a new thread if you are still having issues after this debugging!