How to disqualify a user from a trait (without FTP)?



Our organization uses the DCS API for on-boarding of CRM data (for various reasons, we're not permitted to use the AAM file transfer mechanism).  DCS is fine for qualifying a user for rule-based traits, but how can we disqualify a user?  For example, suppose we have a trait User Gives Consent for which a given user is qualified and later that user withdraws their consent.  To comply with GDPR rules we should disqualify that user within 72 hours.  But how?

If we limit our User Gives Consent trait to a lifetime of 72 hours then okay it'll expire, but then we need to keep refreshing the trait needlessly for all those (possibly millions) of users whose consent doesn't change.  This seems like a brute force solution.  Has anyone else got a better idea?  I did hear rumours of a DCS API upgrade coming in 2019 that would include a trait disqualification feature.  Here's hoping! 

Accepted Solutions (1)

Accepted Solutions (1)




Hello HughBE​,

My name is Ankita Sodhi and I am from AAM Tech Support Team.

I understand that you are looking for a solution on real-time trait disqualification so that opt-in and opt-out can be tracked in AAM.

I would like to highlight that currently we can't remove users from trait in real-time but the same is possible via offline data onboarding method. The feature of removing user from trait in real-time via DCS API calls is a work-in-progress task and we have this on our pipeline.

I do not have any ETA yet which I can confirm on but I can see that our engineering team is engaged into this task and working towards a release.

For now, I suggest that you create a segment using AND NOT logic as mentioned in your scenario, so that it will give you all the users

who are in opt-out list. (Segment rule (opt-out AND NOT opt-in))

I will check on further options and will come back on this thread.

Answers (9)

Answers (9)



Thinking out loud, how about creating another trait (say Trait 2) for users who have withdrawn consent - if we're capturing that action online.

Then a segment can be created for:

Users gives consent Trait


Trait 2 (users who withdrew consent)




Hi david_au

I will get in touch with our engineering team for an expected ETA of completion of this feature and will get back to you with an update.





I have a similer question but with the Onbarded traits for seanerio

Example 1   daty 1  123  "interested"="men"

Example  2  day  2   123  "interested="woment"

Example 3  day  3    123   "interested"="men"

Segment Defination  InterestedMen = Equal Men and not equal to women

But after the then new  trait is onborded I can not be assigined  back to Men as women segment will always  be avalibe  and can be added back to MEN


@ankitasodhi shwetasingh-BYE1k5



Hi ASodhi-AAMShwetaSingh,  following on from my queries in another AAM forum thread, in October 2018 you mentioned that the feature of removing users from traits in real-time via DCS API calls is a work-in-progress task and it is on your engineering pipeline. Can you please advise any reference numbers and the status of this request - we are very excited about this prospect as other options promoted are not useful to our use cases? Many thanks, David.



Indeed, I suspect the AND NOT combinational logic won't solve the problem either...

  1. Let's assume we have defined opt-in and opt-out traits with indefinite lifetimes.
  2. Let's assume all visitors start off qualified for the opt-out trait (meaning that consent has not been given).
  3. Visitor A gives consent and now qualifies for the opt-in trait also.
  4. Visitor B refuses to give consent.
  5. Segment rule (opt-in AND NOT opt-out) -> segment of size 0, so this doesn't help.
  6. Segment rule (opt-out AND NOT opt-in) -> segment of size 1, containing Visitor B.
    Note: This segment definition could just as well have been (NOT opt-in) since opt-out is always TRUE.
  7. So, we could use the second segment rule to come up with an exclusion list.

But as Andrey pointed out, suppose a visitor changes their mind and they revoke their consent.

We've got both traits qualified for Visitor A and we can't undo that (at least not through the API).

Any more ideas?   - Hugh

P.S. Surbhik, the original question was how to do this without FTP file transfer but rather in real-time.



In this case it can get tricky. If you know that your user opts in and opts out that frequently, then probably the best way to go about it would be to upload a batch file of updated list of users. Frequency of the batch file upload can be set to daily.




Christophe_Jossic, could you explain how to approach the following scenario with what is written in the documentation you shared above?

Sequence of Visitor actions:

09 Oct — Opted In — qualification for Trait 1

10 Oct — Opted Out — qualification for Trait 2

11 Oct — Opted In — qualification for Trait 1

Use case:

We want to build a segment that includes the Visitors who have Opted In.