Conditional ask array/donation levels?

Options
We are thinking about how best to use the Donation Levels on a donation form. We often use a dynamic ask based on Highest Gift Amount, but for some donors, the HGA could be $1,000 (or a lot more). That ends up with an level array starting at $1,500, for example.


We have a solicit code in BBCRM for "No High Dollar Asks." Although we are working on getting the solicit code into LO from BBCRM via the Connector, I am wondering if there is a way to present different donation ask arrays to different constituents.


So, for example: One person would see a 10% increase on HGA, and another person might see a 30% increase on HGA. Or perhaps no increase at all--just the static ask array.



PS - I realize we could just have two donation forms and conditionalize an email message, but creating multiple forms could get out of hand and is a lot to keep track of, ultimately. That's why I'm hoping for conditionals on the form.
Tagged:

Comments

  • PPS - Hoping to avoid API form, too.


    Thanks in advance for any insights!!
  • Are you auto-logging them in through the email, so the system knows who they are?
  • Bianca Bickford:

    Are you auto-logging them in through the email, so the system knows who they are?



    Yes, we are.

  • To keep it simple, you could use conditional tags in the email for either last gift amount or HGA, and pass the gift amount variable in the URL that fills out the blank "Other" to get at least one custom level in there.

    Donation2?df_id=XXXX&XXXX.donation=form1&set.DonationLevel=1111&set.Value=1500&autologin=true


    If you wanted to get EXTRA, you could create a lot of different levels then hide the form select options depending on their HGA with jQuery and/or CSS. Makes for a better user experience (and less forms).


    I hope any of that was helpful!
  • Building on Bianca's answer, there's also an S1 tag for largest transaction ... [[S1:largest_trans_amount]]. You could do an E130 tag to evaluate it and modify the set.Value in her URL (also note, the set.DonationLevel won't always be 1111, it'll need to match the ID of your form's user-entered amount field).
  • I've created multiple sets of dynamic ask strings on a single form to achieve something similar. Then use a conditional statement around some CSS to hide one set and show the other. A little JS to preselect the appropriate level helps too. Something like this:

    [[?xx::x[[S1:custom_monetary_value5]]x::/*HIDE HPG18 + STATIC ASKS*/
    .donation-level-container:nth-of-type(-n+10) { display:inline-block; }
    .donation-level-container:nth-of-type(-n+5) { display:none; }
    ::/*HIDE HPG36 + STATIC ASKS*/
    .donation-level-container:nth-of-type(-n+10) { display:none; }
    .donation-level-container:nth-of-type(-n+5) { display:inline-block; }
    ]]

    Then "nth-of-type" stuff is all specific to the number of ask amounts on our forms, so you'd need to sort that out for yours. We've been doing this for a few years and works well. Keeps the logic in the form itself which I find a little easier to maintain than in the email.

  • We have LO and RE, not BBCRM, so don't know if this is relevant. But there are 10 fields in LO called
    "custom_monetary_value"
    We wish we could use Last Gift Amount for Donation ask arrays, but there are a number of reasons that is not accurate for us: 1) non-traditional (not tax-ded) transactions in our database (tend to skew quite low), 2) gifts that are only in RE, not Luminate, and 3) there can only be one last gift, so we can't skip certain gift types.


    So instead we're setting up (haven't done it yet) an import to fill the Custom_monetary_value field; this will become the first ask amount in the donation form gift array. For a long list of reasons, the Ask Amount we use is the Aver Gift over the last 24 months which is why we don't want to use the existing LO field for Aver Gift. We plan to import results from an RE query of the last 24 months of gifts, excluding the types we don't want. Then use the results to populate the LO field = Custom_monetary_value. The plan is to update it weekly using an FTP site and set it up for automated import. That way we don't have to set up the Import each week. It runs on the same* query name each week, so ** Must remember to update that query each week, (but no big disaster if one week it isn't updated, as data is unlikely to change that dramatically).
     
     

Categories