Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subject line - extend the 200 char max length #1909

Closed
benstaf opened this issue Jun 22, 2024 · 4 comments
Closed

Subject line - extend the 200 char max length #1909

benstaf opened this issue Jun 22, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@benstaf
Copy link

benstaf commented Jun 22, 2024

Subject line is limited to 200 characters, it's an issue for coding dynamic subject lines with Go Template language

I would prefer 1000 or 2000 characters for coding the subject line (although the final generated subject line is below 200 characters )

@benstaf benstaf added the enhancement New feature or request label Jun 22, 2024
@knadh knadh self-assigned this Jun 28, 2024
@knadh knadh closed this as completed in c2e7c71 Jul 18, 2024
@latticepublishing
Copy link

@knadh Thanks for building an awesome app! I thought my question might fit well here, but please let me know if I should submit a new issue or something else. I appreciate any help on this, thank you!

I'm trying to integrate my Listmonk instance with my Google Apps Script workflow, but I'm running into this character limitation. I often have campaigns with custom subject lines for each subscriber in the list. These subject lines often only differ by a handful of words or so, but the Go template logic to implement that easily exceeds the limit — which appears to be 5,000 characters from the c2e7c71 commit.

It would seem that I have a few options:

  • Store subject line text (or data needed to create the subject line text) for each campaign on each subscriber's attribs property (not ideal to clutter up the subscribers table with campaign-related data).
  • Split up my campaigns (and lists) into multiple/several smaller campaigns (a lot of additional complexity).
  • Submit a pull request to lift the restriction (but I'm assuming the restriction was applied for performance reasons).
  • Fork the repo and lift the restriction (more leg work and extra complexity to receive future upgrades).

My questions are:

  • Ideally, I would be able to attach some data to each campaign that I could reference in the subject line template similarly to how we can reference subscriber properties. I noticed an archive_meta property on the campaign, but it doesn't appear that I can attach data to that field (perhaps only for archived campaigns?). Do you know of any way I can do something similar?
  • I've never worked with most of these technologies before. Is there anything I'm missing that might help me achieve my custom subject lines? (e.g. external data fetching within a template, storing data in body template and reference it in the subject template, etc.)

Thanks again for your time, I really appreciate it!

@knadh
Copy link
Owner

knadh commented Dec 18, 2024

Hi @latticepublishing

I often have campaigns with custom subject lines for each subscriber in the list. These subject lines often only differ by a handful of words or so, but the Go template logic to implement that easily exceeds the limit — which appears to be 5,000 characters from the c2e7c71 commit.

5000 chars of templating language for the subject line sounds extreme! There must be better ways to orchestrate this.

  • If the subject doesn't not change for a subscriber ever, then it's perfectly fine to construct it and save it in the subscriber's attribs JSON. eg: {"subject": "Final subject here"}

  • If it does change dynamically, you can still store the necessary variables as an arbitrarily nested map in attribs and then use templating logic to compute it in the subject. eg: `{"subject": {"param1": "xx", "param2": "..."}}

JSON attribs has been designed specifically to store arbitrary subscriber-specific data. It is the recommended approach.

There's no per-campaign meta{} support currently (like archive_meta), but it's a consideration for a future version.

@latticepublishing
Copy link

Thanks for the quick reply @knadh !

For clarity on my scenario:

  • We email out results from data analyses to our network of journalists (maybe 50,000 or so) who have opted into receiving emails informing them of each new analysis that might be relevant to their readers.
  • Often, this is segmented by location, like metro. We might have journalists in ~400 different metros.
  • From feedback over the years, we know that the journalists typically prefer to have the hard-hitting stat relevant to their metro right there in the subject line.
  • My subject lines I'm trying to create in Listmonk exceed the 5,000 character threshold because I'm passing in a lot of the hard-hitting stats in the subject template and not attaching it to the subscriber record.

Example subject lines for a recent email campaign:

  • Report: Fresno sees 2nd largest surge in new business applications since 2019
  • Report: Miami sees 61.4% surge in new business applications since 2019
  • Report: DC sees 2nd least growth in new business applications since 2019

Using the approach where we store the data on the subscriber attribs property, these might be templated like so:

  • Report: {{ .Subscriber.Attribs.metro }} sees {{ .Subscriber.Attribs.subjects._213.rank }} surge in new business applications since 2019
  • Report: {{ .Subscriber.Attribs.metro }} sees {{ .Subscriber.Attribs.subjects._213.change }} surge in new business applications since 2019
  • Report: {{ .Subscriber.Attribs.metro }} sees {{ .Subscriber.Attribs.subjects._213.rank }} growth in new business applications since 2019

The _213 bit would correspond to a campaign ID, and the rank and change properties are metro-specific stats. There would also be some additional if/else logic to route each subject line based on metro (<1,000 characters).

This approach keeps the subject line template character count under 5,000, but it attaches a lot of campaign-specific data to the subscriber. Over time, that subscriber record might swell up in size because we send dozens of campaigns per month.

I'd prefer to attach campaign data:

  • Report: {{ .Subscriber.Attribs.metro }} sees {{ index .Campaign.Attribs.rank .Subscriber.Attribs.metro }} surge in new business applications since 2019
  • Report: {{ .Subscriber.Attribs.metro }} sees {{ index .Campaign.Attribs.change .Subscriber.Attribs.metro }} surge in new business applications since 2019
  • Report: {{ .Subscriber.Attribs.metro }} sees {{ index .Campaign.Attribs.rank .Subscriber.Attribs.metro }} growth in new business applications since 2019

With all of that said, it sounds like I don't have access to arbitrary JSON store on the campaign record. So I just have a few questions left:

  • Once a campaign is completed, is there any need to keep the campaign-specific subject properties on the subscriber attribs JSON? In other words, could I remove that data from the subscriber record once the campaign is completed in order to keep it lean?
  • Is there a performance reason to limit the subject templates to be under 5,000 characters? My ultimate subject lines are going to be concise, but the logic to create them is verbose (~50,000–100,000 characters) if I were able to store the data in the subject line template.
  • Is there any sort of plugin infrastructure I could take advantage of to solve my problem? I couldn't find any, but I just thought I'd ask.
  • I was planning to do something similar for my campaign bodies. Is there a character limit to the body templates?

Thanks again for your help!

@knadh
Copy link
Owner

knadh commented Dec 19, 2024

Ah, thanks for the detailed explanation. The ideal solution to this is per-campaign meta, which is on the TODO list for a future version.

Once a campaign is completed, is there any need to keep the campaign-specific subject properties on the subscriber attribs JSON? In other words, could I remove that data from the subscriber record once the campaign is completed in order to keep it lean?

You can remove them.

Is there a performance reason to limit the subject templates to be under 5,000 characters? My ultimate subject lines are going to be concise, but the logic to create them is verbose (~50,000–100,000 characters) if I were able to store the data in the subject line template.

If you have extremely complex subject line templating logic, that naturally adds to the mail processing time. It'll be equivalent to compiling complex mail body templates twice per campaign (complex subject and the actual body). But I don't think this would have a material impact on sending out e-mails, despite an overall slowdown.

But very large subject lines being shown as a small input box isn't good UX. It doesn't make sense from a UI/product perspective, unless the subject field itself is a large textarea, which is a very niche usecase.

Is there any sort of plugin infrastructure I could take advantage of to solve my problem? I couldn't find any, but I just thought I'd ask.
Can't think of anything, unfortunately. With WASM picking up steam, this might change in the future, but nothing right now.

I was planning to do something similar for my campaign bodies. Is there a character limit to the body templates?
No limit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants