historic contact data not available for segmentation

[webnugget]

Some time ago it was possible to add historic contact properties within the ui and I think it was possible to build customer segments based on these fields too.

The only way i could find to add these fields at the moment was to create them via an API Call to
POST: https://api.mailjet.com/v3/REST/contactmetadata which worked fine so far.

Adding historic data via:
POST: https://api.mailjet.com/v3/REST/contactmetadata
works.

And retrieving Historic data for a user via:
GET: https://api.mailjet.com/v3/REST/contacthistorydata?ContactID=xxx@yyy.zzz

also works.

Why isn't this possible for our teammembers via the regular Mailjet UI and why can't our teammembers use these datafields for segmentation of our contactbase.

Is there a workarround for segmentation based on historic fields?

[adamyanliev]

Hello,

Apologies for the delayed response. The reasoning behind removing historic contact properties from the UI is mainly due to stability concerns - it needs to be tested further to understand the limitations for large contact lists and datasets. We are looking into it and may enable it in the future. However, I cannot give you any timeframe at the moment.

I hope this clarifies the situation a bit.

[franz-josef-kaiser]

@adamyanliev as this feature is crucial for us and you closed this issue: Where can find an update once the feature is back in production? Or in other words: Can we somehow register to be updated if you have a roadmap or status updates?

[adamyanliev]

Hey @franz-josef-kaiser I'll make sure to post here when there's any development or status update on the matter. Reopening the issue for now.

Just as an FYI - at the moment there are other development priorities, so it may take a while until we are able to dedicate proper time and resources to this.

Regards,
Atanas

[franz-josef-kaiser]

Thanks @adamyanliev for reopening. I stay subscribed to this issue.
Is there something like a public roadmap for your features or priorities? Or at least something like a "coming up next" list? Just FYI: This would make it much easier to communicate (and negotiate) delays on crucial issues with our stakeholders.

[adamyanliev]

Hi @franz-josef-kaiser - at the moment we don't have a public roadmap. Communication on new features is generally done after release via emails and the Mailjet blog.

Still, thanks for the suggestion, I'll pass it along to management to think over.

[rribcode]

Hi,

I could create a historic property using the API (in Java)... but I am having troubles to add the data (historic data)... and I could not find any documentation...

I have tried so many combinations, but nothing worked...

my last try was:
request = new MailjetRequest(Contacthistorydata.resource)
.property(Contacthistorydata.NAME, "somename")
.property(Contacthistorydata.DATA, "blablabla")
.property(Contacthistorydata.CONTACT, "123456");
response = client.post(request);

I would appreciate if anyone could point me to some documentation or, better yet, if someone could give me an example.

Thanks in advance,
Ricardo

[adamyanliev]

Hi @ricpr23 ,

The information was removed from the official documentation, as we are not officially supporting historic data at the moment. We are working on some improvements on how to store contact properties, but right now this is not one of them.

The resource is not disabled, but we discourage its use. Still, if you want to try it, you can take a look at one of the previous versions of the documentation here (around line 1000):

https://github.com/mailjet/api-documentation/blob/2c594f6896bcb5140fee815e288633901e210d45/guides/_newsletter.md

Here's the actual code sample:

package com.my.project;
import com.mailjet.client.errors.MailjetException;
import com.mailjet.client.errors.MailjetSocketTimeoutException;
import com.mailjet.client.MailjetClient;
import com.mailjet.client.MailjetRequest;
import com.mailjet.client.MailjetResponse;
import com.mailjet.client.resource.Contacthistorydata;
import org.json.JSONArray;
import org.json.JSONObject;
public class MyClass {
    /**
     * Create : This resource can be used to add historical data to contact.
     */
    public static void main(String[] args) throws MailjetException, MailjetSocketTimeoutException {
      MailjetClient client;
      MailjetRequest request;
      MailjetResponse response;
      client = new MailjetClient(System.getenv("MJ_APIKEY_PUBLIC"), System.getenv("MJ_APIKEY_PRIVATE"));
      request = new MailjetRequest(Contacthistorydata.resource)
						.property(Contacthistorydata.CONTACTID, "$CONTACT_ID")
						.property(Contacthistorydata.DATA, "10")
						.property(Contacthistorydata.NAME, "Purchase");
      response = client.post(request);
      System.out.println(response.getStatus());
      System.out.println(response.getData());
    }
}

This is assuming that you've already created the proper contactmetadata object with a historic namespace. Of course, the Contacthistorydata.NAME should match the name of the historic contactmetadata you've created beforehand, and Contacthistorydata.DATA value should be of the same data type you've selected for it.

Regards,
Atanas

[rribcode]

Thank you @adamyanliev !

[franz-josef-kaiser]

Hi @adamyanliev , do you have a rough estimation when this feature might come back? It's essential for us to proceed with MJ to the next level of data usage.

[adamyanliev]

Hi @franz-josef-kaiser , for now there are no plans to reintroduce historic contact data. We're working on other improvements like allowing properties to hold a collection / set of values instead of just a single one.

Let me know if this will be of use to you, and I can leave a comment here when it's released.

[franz-josef-kaiser]

Yes, this would be incredibly useful! Lists are a pain if they are missing or not implemented properly. It forces you to keep either

• sanitized (and therefore not searchable) data and transform it on each create, update or read.
• a single data entry and have a different application and storage available for historic data (not possible for everyone and slow as it is outside your infrastructure).

This means, there is the need to have

• the possible list values configured somewhere.
• validation of input/ request data and proper error messages during create and update calls against the API.

Please keep in mind that each field must have timestamps for GDPR documentation as well (created_at and maybe even updated_at). In case you implement this, historic contact data might become obsolete.

Please do not forget, that all eCommerce solutions are in this case forced to add every single possible purchase as meta data entry to be able to track this for email marketing automation purpose. This could possibly be thousands of entries per record/ contact, even for smaller shops. Just in case you think about adding timeseries storage like InfluxDB, Druid, Prometheus or similar: It might be the better option.

What also would be very useful is if one could define fixed lists for (multi)selections. Example: Language, postal address parts, fav/ interests, etc.