unomi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <>
Subject Re: Centralizing Customer Data in Unomi
Date Fri, 12 Oct 2018 15:40:08 GMT
Hello Michael,

Yes that what it means. You could extend MetadataItem as you have
correctly guessed.

Basically the rule of thumb is to store as much as possible in the
Profile because that were you can really leverage all the power of the
Segmentation and other queries that you could do in Unomi. But if you
need to tie profiles to entities that don't have a direct 1-to-1
relationship (as is the case for households), you might have to define
these new entities as Items.

On Thu, Oct 11, 2018 at 7:59 PM Michael Ghen <> wrote:
> Thanks Serge,.
> re: Or by developing a plugin you could also define your own object type in ElasticSearch
to model a household.
> This is what Extending Unomi with Plugins in the docs talks about, right? This was kind
of what I was thinking of was creating a "profile" for each person and link them to a "household."
Household would be a type I could have to create as an extension, right? I would extend MetadataItem
in Java?
> We also have other entities that are tied to households, like expenses. For these kinds
of entities, is there a critera for what should be implemented as a plugin vs. what should
be added into properties?
> On Thu, Oct 11, 2018 at 12:01 PM Serge Huber <> wrote:
>> Hello Mike,
>> There are different ways you could do this but what comes to mind
>> first would be to have a new "houseHoldID" property for profiles and
>> storing in their the same ID for all members of the same household.
>> The ID could be for example a lastname but would have to be designed
>> to be pretty unique to avoid conflicts.
>> Or you could store an address and simply search for all profiles
>> living at the same address.
>> Or by developing a plugin you could also define your own object type
>> in ElasticSearch to model a household. This is simpler than you think,
>> simply define a Java object class that inherits from MetadataItem and
>> use the persistence service to save and load it. You could then store
>> a reference to this household id in profiles.
>> I hope this helps,
>> Regards,
>>   Serge...
>> On Thu, Oct 11, 2018 at 4:00 PM Michael Ghen <> wrote:
>> >
>> > Hello,
>> >
>> > I have been exploring Unomi for a few weeks now and think it could help us centralize
our customer data. I have a question about what the best way to map our customer data model
to Unomi. I understand its elasticsearch on the backend which isn't a system I have a lot
of experience, so I'm hoping for some recommendations.
>> >
>> > The information we have about our customers includes their household composition.
For example, a customer is a 65 y/o male living with their wife, we have all the personal
information for both people in the household. Another example is a 45 y/o female living with
three children, we have all their information as well.  We provide services to all the people
in the household but there is always a "primary member" identified.
>> >
>> > My question is, how would these customers be modeled in Unomi? I just wondering
what the best way to store the full households information would be given how Unomi works.
We want to have actions and rules based on household attributes like "number of children"
or "number of people over 65." When we perform actions, we need the name and birthdate of
all the people in the household.
>> >
>> > Right now, we do all of this in Ruby on Rails and use a MySQL database.
>> >
>> > Respectfully,
>> >
>> > Mike
>> >

View raw message