Track Button Click by Signed In User

Which data would this be?

:rofl:

1 Like

The fact that they’ve redeemed it.
So in your User Profiles sheet, you have another boolean - “Has Redeemed Offer?” (or whatever)
Then as part of your multi-step action, you set that to ‘true’ when they click on the Redeem Offer button.

Question: Is there more than one offer that a user could redeem? If yes, then it gets a little more complicated :slightly_smiling_face:

1 Like

I was reading through the thread, and was waiting for this can of worms to appear.

3 Likes

This is exactly why I was bombarding you with questions last night :rofl: :rofl:

Just in case the answer to this is yes, here is what I would do:

  • Drop the idea of a boolean in your User Profiles sheet, as you won’t need it
  • Create a new table/sheet, call it something like “Redemptions”
  • This table will contain one row per user, per offer redeemed, and should contain least 3 columns:
    • User ID (a value that uniquely identifies each user, and will allow you to create a relation back to your User Profiles sheet. I’d recommend using the RowID)
    • Offer ID (same as above, but to your Offers sheet)
    • Redeemed At (a date/time column, representing when the user redeemed that offer)

Getting back to the screen where you present the offers…

  • When a user taps the button to redeem an offer, change your action so that it adds a new row to your Redemptions table:
    • UserID (whatever you use to uniquely identify the user)
    • OfferID (ditto for Offers)
    • Redeemed At (current date/time stamp)
  • The counter to track how many times each offer has been redeemed is no longer necessary, as you can do the following:
    • Create a multi-relation between your Offers & Redemptions sheets (Offers.ID → Redemptions.OfferID)
    • Then create a Rollup column in your Offers sheet through that relation (relation → OfferID → count). This will give you a count for each offer.
  • I’d still keep the User Specific column in your Offers table to track when each user redeems each offer, as that’s probably the simplest method.
2 Likes

The advantage of having the offers controlled like this is you can start to have them offered to specific users, maybe based on how long since last log in, you can set offer expiry dates etc etc. far more flexibility (although with more work).

2 Likes

Great thread! :nerd_face::+1:t2:

There will definitely be more than one offer available at a time. :slight_smile: Ok thanks! I will review this.

Ohh I like that!

So I actually would like there to be an expiration for some offers, do I just set the visibility of the redeem button and other components to a date column? I will look into it, but guessing I can put something in there that would display a date ‘30 days from today’ for example.

Include an expiry date column in your Offers table, and don’t present anything where that date is earlier than the current date.

1 Like

Yes! I was thinking this, let’s say I wanted it to expire 30 days from today. Is there a way to add ‘today+30’ or something? Not sure of that as today changes as the days go forward.

I was also having an issue where the ‘today’ counts were off where the offer might expire on Februray 22nd instead of February 23rd like it’s supposed to.

There are lots of different ways to do that. I guess it mostly depends on how you want the user interface to work (both for yourself as an admin, and your users)

You could try this:

When the user claims or redeems the offer, timestamp that user/offer, then use a Math Column to add 30 days from that timestamp.

Then show in the app when that offer will expire via text, action text, wherever, etc.

Then setup an IF-THEN-ELSE, so that if now is after math column expiry date, offer = expired.

1 Like

You could use a maths column if you want to let users “activate” their offers and have an expiry time. Give you a slightly more granular way of administering them. Or simply have a start and end date (waaaaaay easier) which would let you preset future offers.

D+T=E

D=Date
T=Days offer is active
E=Offer expiry

1 Like

Haha yes I was thinking expire as in expire for everyone at the same time. Which ever comes first, they all get used up or it expires. Still thinking of how I would like to do that.

Define the rules, and actually write them down (or type them out). A good chance that will lead you to an obvious solution :slightly_smiling_face:

1 Like

Yes, I’m thinking offers will either have a certain amount available or an expiration date. Will depend on which works best for the said offer.

I’m quite sure we have a similar app/setup…we decided to let the Business Owners decide on expiry dates and # of offer claims available, however we update them in-app/in-sheet. We have more control that way, however tedious it may be.

So that yes, only 100 offers are available, and no matter when someone claims an offer, it will always expire at the end of the month (thanks to Jeff Hager’s glide/math wizardry, Darren knows what I’m talking about :stuck_out_tongue_winking_eye::nerd_face:).

2 Likes

Oh nice! Yup, I will be discussing dates of numbers with the owner.

For the number of offers available, you just add that number to your ‘available’ column right?

1 Like