Tips, Tricks & Best Practices

WhitneyD33
Miembro

Working with referrals on the back end

resolver

Hi all,

 

I've got a theoretical question on how to handle referrals on the back end.

 

We have a form on a landing page (Form A) that when submitted, creates Contact A. Contact A is then redirected to a page that has Form B on it, asking them to refer someone to us. If Contact A fills out Form B, a new contact, Contact B is created (which is what we want!).

 

Here's where I'm having trouble. We have workflows that push Contact A to go to the landing page and fill out the form referring someone to us, which creates Contact B. Since a brand new contact is being created from the submission of Form B (contact B) I can't figure out a way to suppress Contact A from the workflow.

 

Here's what I've tried so far:

-Using clicking the CTA in the workflow email that links to the landing page as the workflow "goal" criteria (I don't love this because just because they clicked the CTA to go to the page doesn't mean they filled out the form

-Creating a custom event on the "submit" button on Form B...however, this tied the event completion to Contact B, not Contact A

 

Any ideas on how we can tie the submission of Form B (which creates a new contact, Contact B) to contact A?

 

Thanks!

1 Soluciones aceptada
Ben_M
Solución
Asesor destacado

Working with referrals on the back end

resolver

What you are asking for could land you in a gray areas or a distinctly spam areas depending on where you are collecting data.

 

The dilemma I see in your workflow is that Contact A has the right to create Contact B. Given this is the case, Contact A is giving you Contact B's information without their consent. In GDPR terms, I am pretty sure this will be considered spam because the message is unsolicited and you are not vetting data before adding someone to your database.

 

In order to be spam compliant in your instance, I would think that your first email touch point would need to be a transactional email stating that they were referred by {Contact A} and to continue receiving emails from you they would need to click a link. At which point, you can capture their data and put them into a workflow.

 

That's part 1.  Part 2 is the tying of the data from Contact A to Contact B to show a linkage. If your model is extremely simplistic you may be able to use text fields to store this data. If you need this data for reporting to see how many times {Contact A} referred a {Contact B} you could also pull form reporting to see all submissions. Just make sure when you capture email for {Contact B} that you are not collecting it in the email field that would overwrite {Contact A}.

 

For an advanced 1 to many relationship (ie: Contact A refers 10 Contact B's), you would need something that is currently not available in Hubspot which is often referred to as a Custom Data Object (CDO). In database terms, this means you would have a another database table that is joined to your contact table to extend the contact table.  If you are not familiar with databases, here's an example. Consider a rewards program at a store. They take your information and assign you a rewards number. The contact table is the data they collect from you at first.  Then they keep a record of a second table of all your purchases (and all other customers' purchases).  The purchase table in this example is the CDO. By joining the contact table with the purchasing table where the customer number is {123} then you can effectively see all purchases made by that specific contact.

Ver la solución en mensaje original publicado

3 Respuestas 3
Ben_M
Solución
Asesor destacado

Working with referrals on the back end

resolver

What you are asking for could land you in a gray areas or a distinctly spam areas depending on where you are collecting data.

 

The dilemma I see in your workflow is that Contact A has the right to create Contact B. Given this is the case, Contact A is giving you Contact B's information without their consent. In GDPR terms, I am pretty sure this will be considered spam because the message is unsolicited and you are not vetting data before adding someone to your database.

 

In order to be spam compliant in your instance, I would think that your first email touch point would need to be a transactional email stating that they were referred by {Contact A} and to continue receiving emails from you they would need to click a link. At which point, you can capture their data and put them into a workflow.

 

That's part 1.  Part 2 is the tying of the data from Contact A to Contact B to show a linkage. If your model is extremely simplistic you may be able to use text fields to store this data. If you need this data for reporting to see how many times {Contact A} referred a {Contact B} you could also pull form reporting to see all submissions. Just make sure when you capture email for {Contact B} that you are not collecting it in the email field that would overwrite {Contact A}.

 

For an advanced 1 to many relationship (ie: Contact A refers 10 Contact B's), you would need something that is currently not available in Hubspot which is often referred to as a Custom Data Object (CDO). In database terms, this means you would have a another database table that is joined to your contact table to extend the contact table.  If you are not familiar with databases, here's an example. Consider a rewards program at a store. They take your information and assign you a rewards number. The contact table is the data they collect from you at first.  Then they keep a record of a second table of all your purchases (and all other customers' purchases).  The purchase table in this example is the CDO. By joining the contact table with the purchasing table where the customer number is {123} then you can effectively see all purchases made by that specific contact.

JMPollock
Miembro

Working with referrals on the back end

resolver

@Ben_M wrote:

What you are asking for could land you in a gray areas or a distinctly spam areas depending on where you are collecting data.

 

The dilemma I see in your workflow is that Contact A has the right to create Contact B. Given this is the case, Contact A is giving you Contact B's information without their consent. In GDPR terms, I am pretty sure this will be considered spam because the message is unsolicited and you are not vetting data before adding someone to your database.

 

In order to be spam compliant in your instance, I would think that your first email touch point would need to be a transactional email stating that they were referred by {Contact A} and to continue receiving emails from you they would need to click a link. At which point, you can capture their data and put them into a workflow.

 

That's part 1.  Part 2 is the tying of the data from Contact A to Contact B to show a linkage. If your model is extremely simplistic you may be able to use text fields to store this data. If you need this data for reporting to see how many times {Contact A} referred a {Contact B} you could also pull form reporting to see all submissions. Just make sure when you capture email for {Contact B} that you are not collecting it in the email field that would overwrite {Contact A}.

 

For an advanced 1 to many relationship (ie: Contact A refers 10 Contact B's), you would need something that is currently not available in Hubspot which is often referred to as a Custom Data Object (CDO). In database terms, this means you would have a another database table that is joined to your contact table to extend the contact table.  If you are not familiar with databases, here's an example. Consider a rewards program at a store. They take your information and assign you a rewards number. The contact table is the data they collect from you at first.  Then they keep a record of a second table of all your purchases (and all other customers' purchases).  The purchase table in this example is the CDO. By joining the contact table with the purchasing table where the customer number is {123} then you can effectively see all purchases made by that specific contact.


This advice was very helpful to me as well, thank you. Is there any way to combine forms so that Contact A enters the contact information for him/herself and Contact B? If so, how is the contact information for Contact B created if Contact A uses the standard Email field? From this, I would want to send Contact B the permission email you mention.

0 Me gusta
WhitneyD33
Miembro

Working with referrals on the back end

resolver

Hi Ben,

 

The GDPR/Spam thing totally makes sense--thanks for your help!

0 Me gusta